Violations

Parsing

Different error that might happen during file parsing phase.

final class ParsingViolation(node=None, text=None)

Bases: BaseFileViolation

Indicates that given file can not be correctly parsed.

This may include: 1. Incorrect OS behavior 2. Incorrect syntax inside this file 3. Errors in our grammar definition 4. Our internal errors

Added in version 0.1.0.

Names

Rules that define how names should be defined.

final class SpacedNameViolation(node, text)

Bases: BaseFSTViolation

Restricts to use duplicate names variables.

Reasoning:

This spaces will be removed by the parsing mechanism, but they might cause some confusion to users.

Solution:

Remove leading spaces.

Example:

# Correct:
SOME_KEY=1

# Wrong:
    SOME_KEY=1

Added in version 0.1.0.

final class IncorrectNameViolation(node, text)

Bases: BaseFSTViolation

Restricts to use restricted symbols to define names.

Reasoning:

By convention we can only use letters, numbers, and underscores to define dotenv variables. Moreover, variables can not start with numbers.

Solution:

Refactor your file to contain only allowed characters.

Example:

# Correct:
SOME_KEY=1

# Wrong:
SOME-KEY=1

Added in version 0.1.0.

final class DuplicateNameViolation(node, text)

Bases: BaseFSTViolation

Restricts to use duplicate names variables.

Reasoning:

There is no need to create duplicate variables inside your dotenv file. Since it will be implicitly overridden by the parsing mechanism.

Solution:

Remove one of the duplicate variables.

Example:

# Correct:
SOME_KEY=1
OTHER_KEY=2

# Wrong:
SOME_KEY=1
SOME_KEY=2

Added in version 0.1.0.

final class RawNameViolation(node, text)

Bases: BaseFSTViolation

Restricts to use raw names without equal sign or value.

Reasoning:

It does not make any sense to just state some names. It might also break some .env parsers.

Solution:

Append equal sign to it. So, this would became a declaration of an empty variable. You can also add a value if it makes sense.

Example:

# Correct:
KEY=1
OTHER=

# Wrong:
KEY

Added in version 0.1.0.

final class ReservedNameViolation(node, text)

Bases: BaseFSTViolation

Restricts to use of blacklisted names.

Reasoning:

It does not make any sense to use such names.

Solution:

Change such names. Or, Add _ at the end, to distinguish it from reserved ones.

Example:

# Wrong:
DJANGO_ENV=some_value

Added in version 0.2.0.

Assigns

Rules that define how assigns should be made.

final class SpacedAssignViolation(node, text)

Bases: BaseFSTViolation

Restricts to write = signs with extra spaces.

Reasoning:

Valid shell syntax requires to write assigns without any spaces.

Solution:

Remove any spaces between the = char.

Example:

# Correct:
KEY=1
OTHER=

# Wrong:
KEY = 1
OTHER =

Added in version 0.1.0.

Values

Rules about writing correct dotenv values.

By convention we do not print values to the output. Since they might contain private values.

final class SpacedValueViolation(node, text)

Bases: BaseFSTViolation

Restricts to write values with trailing spaces.

Reasoning:

These spaces are not guaranteed to be preserved. So, it is better not to rely on them.

Solution:

Remove trailing spaces from the value.

Added in version 0.1.0.

final class QuotedValueViolation(node, text)

Bases: BaseFSTViolation

Restricts to quoted values.

Reasoning:

Dotenv parser usually strips quotes away, so it is hard to say whether these quotes will stay on a final value, or not.

Solution:

Remove any quotes from the value.

Example:

# Correct:
KEY=1

# Wrong:
KEY="1"

Added in version 0.1.0.

Comments

Rules that define how comments should be written.

final class SpacedCommentViolation(node, text)

Bases: BaseFSTViolation

Restricts to write comment with leading or trailing spaces.

Reasoning:

These spaces are meaningless and will be removed. So, why would you want to have them?

Solution:

Remove leading or trailing spaces from the comment body.

Added in version 0.1.0.