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

Revert "nixos: default environment.homeBinInPath to false" #83881

Closed
wants to merge 1 commit into from

Conversation

edolstra
Copy link
Member

This reverts commit a06529b. Having ~/bin in $PATH has been the case in NixOS since forever or so, so I don't see a strong reason for changing this. People who don't want this can set environment.homeBinInPath to false now.

This reverts commit a06529b. Having
~/bin in $PATH has been the case in NixOS since forever or so, so I
don't see a strong reason for changing this. People who don't want
this can set environment.homeBinInPath to false now.
@edolstra edolstra added this to the 20.03 milestone Mar 31, 2020
@worldofpeace worldofpeace requested a review from andir March 31, 2020 18:33
Copy link
Contributor

@jonringer jonringer left a comment

Choose a reason for hiding this comment

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

would still like @andir opinion

@andir
Copy link
Member

andir commented Mar 31, 2020

I would argue that the more common case is to NOT have it on your path and if you need that you can opt-in to it. We have a proper release note entry documenting it. If we revert this how can we ever deprecate something?

@rnhmjoj
Copy link
Contributor

rnhmjoj commented Apr 1, 2020

I don't really see the point of this option being in NixOS. It's something that can be done trivially in the user .profile or via environment.variables.PATH in NixOS.

@edolstra
Copy link
Member Author

edolstra commented Apr 1, 2020

We've had this discussion before and the result was not to remove it (#40065). IMHO nothing has really changed since then.

@dasJ
Copy link
Member

dasJ commented Apr 1, 2020

-1 on this

Encouraging impurities like that should be kept to a minimum by default

@andir
Copy link
Member

andir commented Apr 1, 2020

Looking at the old discussion we did lack a proper way of dealing with deprecation. I think we do have one and that is called release notes and a way to revert to the old (potentially never desired behavior). The change is listed in the category for breaking changes and has an almost copy-able line that enables the old mode of operation. (If you depend on this you should set the option <literal>environment.homeBinInPath</literal> to <literal>true</literal>.)

We have had two users (you and @xeji) of use this. I am not sure if @xeji was aware of the feature since he stated it comes from his dotfiles repo anyway.

The majority of people reacting to see seem to be against this PR - as far as you can trust GH reactions…
I am missing really good arguments why this is a good default for everyone. Ignoring the fact that it was default for many years now.

Once upon a time I also had a ~/bin folder but ever since I switched to NixOS I like my scripts to be not mutable anymore… Not sure if that counts as a counter argument.

@adisbladis
Copy link
Member

environment.homeBinInPath = true is a highly surprising default, especially given that we strive for purity.

I'm strongly against this PR.

@jonringer
Copy link
Contributor

environment.homeBinInPath = true is a highly surprising default, especially given that we strive for purity.

On the flip side, people trying nixos might find it highly surprising that it's not there. I think it's just a matter of perspective. For the purity argument, I agree that the NixOS system probably shouldn't have any knowledge of a given user's HOME directory.

I guess I don't feel strongly about this. Those that need ~/bin on their path will probably do the correct steps to ensure it's there, while those don't use it will likely never know it's there.

@joepie91
Copy link
Contributor

joepie91 commented Apr 1, 2020

On the flip side, people trying nixos might find it highly surprising that it's not there.

On the other hand, has the ship of non-surprising behaviour not already kinda sailed considering there's effectively no /bin or /lib either?

I mean, we have basically two options here:

  1. Add another "difference with other distros" to the list, but a difference that is consistent with the NixOS design rationale.
  2. Avoid differing from other distros for this one small bit, and then have to explain why this is an exception to the overall design rationale.

I feel like considering the circumstances, option 1 would probably be preferable?

@gilligan
Copy link
Contributor

gilligan commented Apr 1, 2020

Opting for ~/bin to be in PATH simply because it has always been that way isn't very convincing to me. Why isn't now the right time to do the right thing in this regard? There aren't currently any rules regarding a stable API or anything like that which would prevent this change (?).

TL;DR: I'd prefer for this to not be merged. Not having ~/bin in PATH sounds more desirable to me.

@jonringer
Copy link
Contributor

jonringer commented Apr 1, 2020

Related to the "similar to other distro's" topic is a discussion that already occurred on discourse: https://discourse.nixos.org/t/why-i-switched-to-manjaro-linux/5903/22.

If we decide to include such a thing in nixos, people who want a more "batteries-included" experience can opt into importing a "profile", which will create a desktop environment with all the defaults taken from an opinionated distro.

E.g:

  imports = [
    ./hardware-configuration.nix
    <nixos/profiles/ubuntu>
  ];

Edit: this does create the overhead of trying to "keep-up-to-date" with the other distros. But at least for a user, they are able to get a gnome desktop, firefox, and many other applications with just one line instead of many.

@edolstra
Copy link
Member Author

edolstra commented Apr 3, 2020

The issue is not what other Linux distros do, it's what NixOS has done for the last decade or so. If you don't want ~/bin to be used, the simple solution is to not have a ~/bin.

@edolstra
Copy link
Member Author

edolstra commented Apr 3, 2020

I'll bow to the will of the people and close this PR.

@edolstra edolstra closed this Apr 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants