If other distros allow pip-installing into the system, that could be considered a bug or at least an anti-feature, because it's almost always a bad idea: it can clash with distro-managed Python packages, it will break on Python upgrades, and sooner or later you will run into version conflicts (a.k.a. DLL Hell). Recent versions of pip refuse to install into the system by default, for all of these reasons.
It's better to instead pip-install Python packages into virtual environments, recent Pythons havr `venv` built in for this purpose. For user-scoped or system-scoped utilities, `pipx` can manage dedicated virtual environments and symlink them into the search path.
Nix purists would say that you should use flakes to declare all the dependencies for each project, and reference all Python dependencies as Nix packages there. Nix effectively tries to replace every package manager in existence, so all Python, Ruby, Emacs, etc. dependency trees are duplicated in Nix.
I think this is insane. Not only will many packages be missing from Nix, you will also have to wait for the upstream changes to actually propagate to Nix repositories. This all assumes, of course, that there are no packaging issues or incompatibilities in this repackaging.
This is one of the ways that Nix sometimes just gets in your way. I've been using Nix(OS) for several years now, and this still bothers me.
Instead of doing this, For Python specifically I would suggest installing pyenv, which Nix packages. Then enter a nix-shell with a derivation thingie[1,2], and install Python as usual with pyenv. Then you can use any Python version, and with pyenv-virtualenv (which Nix _doesn't_ package...), you can use venvs as you're used to. Sure, you don't get the benefits of the declarative approach and isolation as with "the Nix way", and you may run into other issues, but at least it's a workflow well known to Python devs. Hope it helps!
The right way is to compose the base Python package with the libraries you want. For example, this gives you an ephemeral environment with the latest python3 plus NumPy:
In case of Python, you can also go for a simpler option that avoids composing Python with its packages, but that gives worse isolation:
nix-shell -p python3 python3Packages.numpy
If other packages were present in that ephemeral environment, aside from python3, they could see NumPy in a global directory. That's why the first option is preferable, as it offers better isolation. In Nix, some languages only let you use libraries with something like the first option. See the Nix user wiki for further information: https://nixos.wiki/wiki/Python.
I'm new as well - it's good to remember that NixOS, nix-shell, and the programming language of Nix are all separate. You can start with your current distro to learn nix-shell first.
I still have no idea how it all works but it seemed prudent for me to at least try.
The correct answer, whatever distro, is to either use the system package manager or use python's venvs. Mixing multiple package managers in a given area of the filesystem is a recipe for breakage.
Thanks for the suggestion, I'm aware of this resource but it's not what I'm looking for -- for example, it recommends SICP and Berkeley's 61A lectures for learning programming.
I'm very familiar with both resources -- the former is how I learned to code, and I actually took the second class in person at Berkeley. But I have a math background, and mostly don't have math trauma anymore
This is for a person with math trauma who dropped out in middle school. The goal is to get her comfortable with the ideas and methods of CS, at least enough that she'll eventually be ready to tackle deeper resources like those one day if she wants to. I think introducing those at this stage would be overwhelming and disheartening.
I do like those resources for folks with more traditional backgrounds and preparation though
Just putting this here: I am using denote nowadays after org-roam and while it's not org-roam (I miss the dailies) it gets some stuff really right (tags, directories)
