Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid lines silently stops parsing remaining lines #4

Open
polarathene opened this issue Oct 18, 2023 · 2 comments · May be fixed by #5
Open

Invalid lines silently stops parsing remaining lines #4

polarathene opened this issue Oct 18, 2023 · 2 comments · May be fixed by #5

Comments

@polarathene
Copy link

Reference: allan2/dotenvy#11 (comment)

A=foo bar
B="notenough
C='toomany''
D=valid
export NOT_SET
E=valid

I've added the two valid lines, if you remove the C line, D will be included, likewise the unset export line would also need to be removed for E to be successfully parsed.

It seems if any invalid line is encountered no further lines are parsed? They should probably raise an error, or at the very least continue parsing the valid lines?

jsirois added a commit to jsirois/dotenvs-rs that referenced this issue Nov 4, 2023
Refactor `dotenv::dotenv::Iter` to expose parse errors for those
interested. The parse errors are structured as opaque strings to hide
the parsing implementation details (currently nom and nom's errors are
the internal currency).

This allows a consumer that cares about propagating errors in `.env`
files to use something like:
```
let env = dotenv::from_filename(".env")?;
let mut iter = env.iter();
while let Some((key, value)) = iter.try_next()? {
    if std::env::var(key).is_err() {
        std::env::set_var(key, value);
    }
}
```

Fixes arniu#4
@jsirois jsirois linked a pull request Nov 4, 2023 that will close this issue
@jsirois
Copy link

jsirois commented Nov 4, 2023

I took a stab at this in #5 because I have a need for failing fast if .env files are invalid over in scie-jump. I took a minimal approach here though and left the current APIs as-is, but added a new, minimal one to allow folks interested in .env parse errors to handle them as they see fit. @arniu let me know if this is way off base or if you'd prefer to be more aggressive and actually change the existing load API to propagate errors as @polarathene seems to be pushing for.

jsirois added a commit to jsirois/dotenvs-rs that referenced this issue Nov 4, 2023
jsirois added a commit to jsirois/dotenvs-rs that referenced this issue Nov 4, 2023
Refactor `dotenv::dotenv::Iter` to expose parse errors for those
interested. The parse errors are structured as opaque strings to hide
the parsing implementation details (currently nom and nom's errors are
the internal currency).

This allows a consumer that cares about propagating errors in `.env`
files to use something like:
```
let env = dotenv::from_filename(".env")?;
let mut iter = env.iter();
while let Some((key, value)) = iter.try_next()? {
    if std::env::var(key).is_err() {
        std::env::set_var(key, value);
    }
}
```

Fixes arniu#4
@jsirois
Copy link

jsirois commented Dec 22, 2023

I'm now using a fork of this repo with #5 (See: a-scie/jump#180). I'd love to depend on the crate instead and I definitely don't want to introduce a forked crate (there are too many already!) for .env loading on crates.io. If there is anything I can do to help move this forward up to and including taking over / helping with maintenance for this project, I'd be happy to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants