1. 4
  1.  

  2. 4

    I feel like the author tends to panic and overcomplicate their justifications, rather than relaxing a little and modifying their desires. It is quite acceptable for a request for Python 3 to give the wrong minor version but the right major version, I think. Their prior posts suggest that they have all the knowledge required to incant:

    $ nix-shell -p python38
    

    This is mentioned in the Python section of the manual:

    It is also possible to refer to specific versions, e.g. python38 refers to CPython 3.8, and pypy refers to the default PyPy interpreter.

    The author is wrong in their claim that this will bite new users; new users are generally asked to use a stable release, where the CPython 3.x version is 3.8.8, and the author is only bitten by this because they’re using an unstable branch.

    1. 2

      I feel like the author tends to panic and overcomplicate their justifications, rather than relaxing a little and modifying their desires.

      My desire is, well, to learn about Nix, and this was a valuable journey for me in learning more about package name disambiguation. I don’t use nix-env -u anymore, because I know that it doesn’t work, and I have no problems using a Nix-installed Python myself.

      (I think there’s a very good argument to be made that package name-based operations are so broken that trying to smooth over papercuts like this is pointless, and we would be much better served by just getting rid of nix-env -u and unqualified nix-env -i altogether. But that ignores that the point of this post is to practice writing overrides :)

      The author is wrong in their claim that this will bite new users

      Well, this bit me when I was a new user, and I wrote this in response to an email from another new user who ran into the same problem (but did not yet understand how to fix it). So it’s so far bitten at least two new Nix users, and I think I would stand by that weaker paraphrased claim. My actual claim was very hyperbolic:

      every single new Nix user is going to run that first thing because that’s the “obvious” command and it’s what the quick start guide told them to run and on and on and on.

      Which I think is pretty easily refutable. (e.g. not all new Nix users will install python3, not all new Nix users read the Nix manual, etc)

      the author is only bitten by this because they’re using an unstable branch

      I’m not sure why you say that. This is the case in the latest stable NixOS channel:

      $ nix-env -i python3 --file https://nixos.org/channels/nixos-21.05/nixexprs.tar.xz
      installing 'python3-3.10.0a5'
      ...
      

      (Although I may have misunderstood what you meant.)

      1. 1

        Your shell snippet is disingenuous; it is not loading the 21.05 release channel. Here’s a REPL session:

        $ nix repl https://nixos.org/channels/nixos-21.05/nixexprs.tar.xz
        Welcome to Nix version 2.3.10. Type :? for help.
        
        Loading 'https://nixos.org/channels/nixos-21.05/nixexprs.tar.xz'...
        Added 14198 variables.
        
        nix-repl> python3.version
        "3.8.9"
        
        nix-repl> python38.version
        "3.8.9"
        

        My system channel is on 20.09 and retrieves CPython 3.8.8, explaining the discrepancy between my original post and this one. I don’t understand how your channels are configured, but the usage of nix-env is going to continue to confound your experiments.

        1. 2

          Can you explain what I got wrong? I cannot find the error in my shell snippet.

          You are commenting on a post about the name-based disambiguation performed by nix-env -i and nix-env -u. I’m not sure what you mean by “the usage of nix-env is going to continue to confound your experiments.” No other Nix commands operate on package names, as far as I know.

          I would paraphrase the post in this short way: “nix-env -i python3 is different from nix-env -iA nixpkgs.python3.” Your snippet demonstrates the second half of that statement: that nixpkgs.python3 is a stable release of CPython. The original post points this out in multiple places. My snippet in the GP demonstrates the first half: the package “named” python3 (following nix-env’s disambiguation rules) is a (broken) pre-release.

      2. 1

        Why is he using an unstable channel?

        1. 4

          Great question! nixpkgs-unstable is the default channel that you get when you install Nix. Although NixOS by default uses a “stable” release, if you just install nix on a non-NixOS machine, you’re living the unstable life.

          It’s worth noting that the python3 versioning issue is present in the latest stable NixOS release as well; there is nothing in the source article that is dependent on using the (default) unstable channel, despite claims to the contrary.

          1. 1

            Without mind-reading, I can only guess that they wanted it and chose it. I’ve made the same choice before, and often run directly from the master branch of the main git repository, which is even more unstable. But we can’t ignore the choice; by default, new users are given a much more stable release branch which is vetted and tested, and the author chose a different experience.

            1. 1

              I thought maybe it was mentioned somewhere in the series and I just couldn’t find it.

              It might also just be a lack of guidance in the installation documents. Since, if you don’t really know what the channels mean you might think unstable is like using a non-LTS Ubuntu.

        2. 3

          Ha, I’m amused that my email to you sparked a whole blog post. Thanks for putting the work in.

          Unfortunately I’m just finding that Nix has such a steep learning curve, with so much hidden complexity, that I just don’t want to learn it. The “Basic package management” section of the manual, which comes right after installation, outlines commands that apparently one should never use. This section is about as far as I read before thinking I had a good enough grasp on the tools to “get going” with Nix, and I can see many people doing similarly.

          Some combination of the syntax, the conceptual complexity and the poor documentation is just telling me “This isn’t worth it. Just use Debian stable if you want stability, or Arch if you want cutting-edge.”

          By the way, the reason I want to install Python 3 in my environment generally is that I use it quite often as a shell scripting langage instead of Bash. I don’t manage my ad-hoc shell scripts via Nix; they just sit in ~/.local/bin, so there needs to be a Python in my environemnt.

          1. 2

            I think that your experience is a very common one.

            Some people come to Nix via a mentor – a friend or colleague who understands it, and is able to offer helpful advice for new users. Especially: this is the subset of Nix you should actually use; don’t use nix-env -i or nix-env -u. Don’t read the manual: it is full of lies.

            And some people come on their own, expecting to teach themselves Nix from scratch. This is a much more difficult journey, given the current state of the manual. And while there are hundreds of unofficial resources out there that explain how to use Nix “correctly,” some of which might be quite good, it’s hard to find those or know which are correct or complete or up-to-date. This is further complicated by the fact that many “real” Nix users are using the unstable 2.4 release of Nix, which adds lots of nice features and fixes lots of annoying problems – and many guides assume that you are also using a pre-release Nix. Which you aren’t, if you just installed the official installation instructions, and which you probably don’t want to use and probably don’t even know how to install.

            Unfortunately a lot of this is an emphasis (in the manual) on using Nix like a traditional package manager. But Nix offers very little marginal improvement to that use case, and adds lots of rough edges, as you encountered. The actual value of Nix comes from the things it can do that other package managers cannot: per-project dependencies, ad-hoc environments, conflict-free installation of multiple versions, atomic rollbacks, blah blah blah. These are things you might not care much about until you try them, but they are the reason to put up with all of the complexity and rough edges.

            But it takes a lot of knowledge and practice and frustration before you’re able to benefit from these weird features. And the manual is no help: it doesn’t really emphasize these use-cases, and instead (mostly) treats Nix like just another package manager.

            All of that is to say: Debian and Arch are in fact valid alternatives to that part of Nix. But not to the Nix-unique features. But why would you stick around long enough to find out?

            So, yeah, I’m just rambling now. Thank you for sharing your experience; it makes perfect sense to me why you would not want to continue learning Nix. Hopefully one day soon this will get better, and Nix will be easier to self-teach yourself, and the manual will not lead new users astray.