Seems like we'll want to cover these tests https://github.com/theskumar/python-dotenv/blob/main/tests/test_parser.py

We'd want to use https://github.com/tweag/nix-unit-testing/tree/main/flake to write the tests.

#718 can also fix this issue by offloading the whole parsing logic to the shell. It also means that config.env won't hold variables extracted from the .env file, but it's not like config.env was guaranteed to hold all the environment variables available in devenv shell, since any enterShell script can add its own environment variable.

I was looking into tweaking the regex used in parseLine to make it ignore comments, but I'm beginning to think #718 may be the smarter approach. (Or at least in that general direction - #718 doesn't handle comments well as-is)

@domenkozar What do you think?

#718 can also fix this issue by offloading the whole parsing logic to the shell. It also means that config.env won't hold variables extracted from the .env file, but it's not like config.env was guaranteed to hold all the environment variables available in devenv shell, since any enterShell script can add its own environment variable.

I was looking into tweaking the regex used in parseLine to make it ignore comments, but I'm beginning to think #718 may be the smarter approach. (Or at least in that general direction - #718 doesn't handle comments well as-is)

@domenkozar What do you think?

My worry is that if someone relies on those variables to be used in Nix, this will stop working.

I don't know if this needs a new issue or not, but the regex in question also seems to cause problems with values that have = in them. The "(.+) *= *(.+)" regex is greedy so everything up to the last = is captured as the variable name. For example, a typical database url environment variable such as DATABASE_URL=postgresql://postgres:postgres@localhost:5432/postgres?schema=public seems to be read in with a name of DATABASE_URL=postgresql://postgres:postgres@localhost:5432/postgres?schema instead of the expected name of DATABASE_URL.

I will second the ability to have the .env variables accessed in Nix is pretty useful. It lets me easily parameterize parts of an environment variable across environments, such as the port of the database url in the example above.

Yeah, on second thoughts, I can use direnv to source .env if I don't need the env vars to be available in config.env.

I have a regex that can handle comments and values with = somewhat, but the actual values don't get stripped of comments until after they've been exported as environment variables: https://gist.github.com/ento/765b47da99cc05d4fec508632e8d1f64 (and it doesn't handle quotes at all, as demonstrated by the test cases in that gist)

I will second the ability to have the .env variables accessed in Nix is pretty useful.

I am not sure if it is a good idea to access .env variables in nix expressions. For example, if you create a script via pkgs.writeShellScript, in which the variable is referenced via env.DATABASE_URL, then your pgsql password is leaked to the nix store, which is visible to all unix users. On the other hand, if your shell script references it via $DATABASE_URL, your pgsql password would not be leaked to the nix store.