-
Notifications
You must be signed in to change notification settings - Fork 24
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
Remove option-ext dependency #26
Conversation
Sorry, but I like it the way it is. |
Why? |
A dependency for such a trivial operation is rather on the bloatful side, but most importantly, extends the virality of its copyleft MPL license to this MIT/Apache-licensed crate, which does not make much sense: Can this decision be reconsidered, please? This alone is a reason to stay on Edit: @kpcyrd, the reason @soc mentioned for this being the way it is can be read here: e169da7#r109131407 |
I noticed this PR is an exact duplicate of #24. |
? |
I wrote that comment before properly researching the situation with this dependency. At the moment, I have no new arguments to add to the discussion about why the dependency on |
I'd like to join the request - my org forbids the usage of crates using a copyleft license even as an indirect dependency. |
@nihohit That's fine. Orgs that object even to the tiniest bit of responsibility are "customers" that I can easily do without. |
It seems like the project ended up with two different dependencies providing access to the home directory. This PR consolidates these dependencies into a single dependency. I've done so by using the `home` crate since on linux it has 0 dependencies and is well supported due to being a part of the cargo repo. But if you'd prefer I could swap this PR to use `dirs-next`. I would like to avoid `dirs` since it is pulling in strange dependencies dirs-dev/dirs-sys-rs#26
I found a way to replace the use of this dependency with a trivial compare.