Violations

Parsing

Different error that might happen during file parsing phase.

class ParsingViolation(node=None, text=None)[source]

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.

class SpacedNameViolation(node, text)[source]

Bases: BaseFSTViolation

Restricts to use leading spaces in 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.

class IncorrectNameViolation(node, text)[source]

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.

class DuplicateNameViolation(node, text)[source]

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.

class RawNameViolation(node, text)[source]

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.

class ReservedNameViolation(node, text)[source]

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.

class SpacedAssignViolation(node, text)[source]

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.

class SpacedValueViolation(node, text)[source]

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.

class QuotedValueViolation(node, text)[source]

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.

class InvalidEOLViolation(node, text)[source]

Bases: BaseFSTViolation

Restricts to use rn (CRLF) end-of-line.

Reasoning:

Mixing different end-of-line chars can lead to different hard-to-debug problems.

Solution:

Use n (LF) end-of-line. Another option is to add line text eol=lf to .gitattributes.

Added in version 0.6.0.

Comments

Rules that define how comments should be written.

class SpacedCommentViolation(node, text)[source]

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.