support parsing .env and returning a Dictionary<string,string> instead of modifying environment about dotnet-env HOT 13 CLOSED

I don't personally need/use any variable interpolation, my target .env just has regular foo=bar pairs, I'm never going to use the interpolation support. As a user, I just want a library that will just parse the .env file, I don't want it touching the environment at all. Separate Load and Parse methods were kind of the intent, either "parse the file, return to me what you find" or "parse the file, load it up into the current environment, optionally return it". I prefer dict to enum kvp just so I can dict["FOO"] as a consumer more easily and not have to worry about what's returned having duplicated keys

from dotnet-env.

Version 2.0.0 is out with this included! https://www.nuget.org/packages/DotNetEnv/2.0.0/

You can return a Dictionary with ToDictionary() on the result from load, so the full version of what you want (with traversing up for .env) is:

DotNetEnv.Env.TraversePath().Load().ToDictionary();

from dotnet-env.

That’s awesome! Thanks @rogusdev !!

from dotnet-env.

@rogusdev would you be ok with this kind of change? If so, would you prefer it as new static Parse calls on the existing Env class that returned Dictionary<string,string> or surface as a new class (presumably wanting to keep Parser internal)?

I had started down the path of adding 4 static Parse calls to Env (path, lines, stream, default - same overloads as Load) and added tests for them but wanted to find out what you would prefer before opening a PR.

from dotnet-env.

Sure, I would welcome a PR like that! It would just be a new parsetodict method or something -- maybe rename the old methods to parsetoenv and add deprecation attributes on methods named the old way for backwards compatibility that point to parsetoenv

from dotnet-env.

As noted on your PR #42 , this will be handled by the upcoming dotnet-env 2.0, which you can see a preview of here: rogusdev@1204d05 (I just need to fix up all the old tests, which will take a bit) -- the solution is a new loadoption to determine if env vars should be parsed while loading or not (meaning should there be any writing of env vars during parsing so that any $ENVVAR references can subsequently be loaded in later .env lines) -- and all load functions now return the IEnumerable<KeyValuePair<string,string>> which matches the signature of the configuration builder extension you linked (and is convenient in this new approach already).

from dotnet-env.

Actually, before I do too much more work, is it your desire that:

1. loading/parsing does not modify the env vars as your issue title says
   or
2. variables in .env files are not interpolated/populated/inflated such that they remain as $ENVVAR
   or
3. both/either, depending

The trick is an example like:

TRICKY_VAR="$EXISTING_VAR"

where EXISTING_VAR in the env when parsed is equal to hello

Do you want to have Load return a dict / ienumerable of kvps that has:

1. "TRICKY_VAR" => "hello" (the value of the referenced/interpolated env var in the .env assignment value)
   or
2. "TRICKY_VAR" => "$EXISTING_VAR" (the actual string with a dollar sign and name of the variable, not its value)

And then separately, afterwards, should:

1. env | grep TRICKY_VAR return nothing, because no env vars were modified?
   or
2. env | grep TRICKY_VAR return `TRICKY_VAR=hello" (or "TRICKY_VAR=$EXISTING_VAR", depending on the first question) because the env var was in fact set?

I'm not really familiar with your use case and I can imagine both being theoretically possible but I don't want to add feature bloat that no one wants.

from dotnet-env.

New PR is up for this, would love your review: #44

from dotnet-env.

I'd also prefer something that would automatically look up the directory hierarchy for the .env like some similar libraries do, but I can live without that. 😄

from dotnet-env.

Can you create a separate issue for the directory hierarchy request, and elaborate there?

from dotnet-env.

The new setEnvVars option does what you want then. Is that acceptable for you?

from dotnet-env.

@jamesmanning is this what you mean about looking up the directory hierarchy for .env files? rogusdev#2 I have not noticed other projects providing this feature however, and I am mildly concerned that it could lead to mysterious undesired behavior for some users. Can you point me at existing projects using this?

from dotnet-env.

@jamesmanning is this what you mean about looking up the directory hierarchy for .env files? rogusdev#2

Yes, exactly

I have not noticed other projects providing this feature however, and I am mildly concerned that it could lead to mysterious undesired behavior for some users. Can you point me at existing projects using this?

https://github.com/bolorundurowb/dotenv.net#autoconfig

from dotnet-env.