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

More idiomatic code #57

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

More idiomatic code #57

wants to merge 4 commits into from

Conversation

jplatte
Copy link

@jplatte jplatte commented Jul 7, 2020

Are these clear enough the way they are or should any of the changes have more explanation?

None of them really use it to convert Result to Option
@codecov
Copy link

codecov bot commented Jul 7, 2020

Codecov Report

Merging #57 into master will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #57   +/-   ##
=======================================
  Coverage   86.77%   86.77%           
=======================================
  Files           7        7           
  Lines         242      242           
=======================================
  Hits          210      210           
  Misses         32       32           
Impacted Files Coverage Δ
dotenv/src/parse.rs 95.34% <ø> (ø)
dotenv/src/lib.rs 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3c1a77b...a077484. Read the comment docs.

dotenv/src/parse.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@Plecra Plecra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative to .ok() is interesting! I admit this syntax does seem like more idiomatic Rust, rather than just kinda hiding the must_use annotation on Results. I wonder if users will find the change jarring though... Personally I like it ^^

@jplatte
Copy link
Author

jplatte commented Jul 13, 2020

The alternative to .ok() is interesting! I admit this syntax does seem like more idiomatic Rust, rather than just kinda hiding the must_use annotation on Results. I wonder if users will find the change jarring though... Personally I like it ^^

Do you expect me do anything here, e.g. leave that commit out for now?

@Plecra
Copy link
Contributor

Plecra commented Jul 14, 2020

Sorry for being vague: I'm not a maintainer of this repository, so there's no need to follow my recommendations. I am hoping the let _ style sticks though 😀

Btw, there's an equivalent Result::expect_err method you can use in the same way on the other tests (Ooh, you still need to match on the LineParse)

@jplatte
Copy link
Author

jplatte commented Jul 14, 2020

Yes, the LineParse matching is why I couldn't update under others (I wanted to).

@jplatte
Copy link
Author

jplatte commented Oct 2, 2020

Ping @ZoeyR

@ZoeyR
Copy link
Contributor

ZoeyR commented Oct 9, 2020

I am without computer and decent internet for a bit. I'll start working on PRs once I have those in place.

Copy link
Contributor

@ZoeyR ZoeyR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, there are just two places where some extra whitespace was accidentally removed.

dotenv/src/parse.rs Outdated Show resolved Hide resolved
dotenv/src/parse.rs Outdated Show resolved Hide resolved
@jplatte
Copy link
Author

jplatte commented Dec 1, 2020

Ping @ZoeyR

@jplatte
Copy link
Author

jplatte commented May 6, 2021

@ZoeyR any chances you could have another look at this soon, or add another maintainer to the dotenv-rs org?

@tshepang
Copy link

The alternative to .ok() is interesting! I admit this syntax does seem like more idiomatic Rust, rather than just kinda hiding the must_use annotation on Results. I wonder if users will find the change jarring though... Personally I like it ^^

I find it jarring, and think dotenv.ok() makes it clear enough that failure is acceptable (meaning that .env is more a convenience than a requirement of the resulting executable).

@kaj
Copy link

kaj commented Dec 13, 2021

In projects where I don't want random crashes, I use dotenv like this:

    match dotenv() {
        Ok(_) => (),
        Err(ref err) if err.not_found() => (),
        Err(e) => return Err(e.into()),
    }

I would very much prefer to just have:

    dotenv()?;

... but I do not want an error if there is no .env file. However, I desperatley do want an error in case of an imparsable .env file.

allan2 referenced this pull request in allan2/dotenvy Feb 28, 2022
The following is also duplicated in the changelog.

- `dotenv` crate forked as `dotenvy`
- `dotenv_codegen` forked as `dotenvy_codgen`
- `dotenv_codegen_implementation` forked as `dotenvy_codegen_impl`
- Crate description for dotenvy_codegen
- Crate description for dotenvy_codgen_impl
- New language in README
- MIT license badge in README
- Generate helpful errors from dotenv! macro (full merge of [dotenv-rs/dotenv #58](https://github.com/dotenv-rs/dotenv/pull/57/files#))

- replaced deprecated `std::env_home:dir()` with `dirs:home_dir`
- Better handling of `home_dir` (merge of [dotenv-rs/dotenv #62](https://github.com/dotenv-rs/dotenv/pull/62/files#))
- assertions dealing with `Result` (based on [dotenv-rs/dotenv #57](https://github.com/dotenv-rs/dotenv/pull/57/files#))
- upgraded clap in `dotenvy` bin from v2 to v3.1 (covers [dotenv-rs/dotenv #76](https://github.com/dotenv-rs/dotenv/pull/76/files))

- example folder. The simple example has been moved to the README.
- `extern`
- unnecessary `use` statements in doc examples
@allan2
Copy link

allan2 commented Feb 28, 2022

@jplatte I just wanted to mention that I merged this into my fork of dotenv called dotenvy.
Thanks for the PR!

@hoijui
Copy link

hoijui commented Mar 7, 2022

@allan2's repo is now considered the new upstream, so just use it instead of this repo.

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 this pull request may close these issues.

7 participants