4 ms·

It seems most package managers were built with the assumption that you will stick to a single, officially sanctioned version of the language runtime and core li

by kijin 3y ago

It seems most package managers were built with the assumption that you will stick to a single, officially sanctioned version of the language runtime and core libraries. Which is a reasonable assumption to make, for example, if the language in question is also used by system utilities in a traditional Linux distribution. You really don't want yum invoking the wrong version of python. For newer languages that change fast, though, we need something different. I don't think "every project brings in its own language runtime and the kitchen sink" is a sustainable situation, either. The dependency graph is crazy enough already.

woodruffw 3y ago
> Which is a reasonable assumption to make, for example, if the language in question is also used by system utilities in a traditional Linux distribution. You really don't want yum invoking the wrong version of python. Yep, this is the core reason: there needs to be a "system" distribution of Python, Ruby, etc. for packages written in those languages, and that distribution fundamentally needs to prioritize the interests of the package manager over "external" uses. This is particularly painful in the Python world, since using a "system" Python distribution for local development can break the system itself in all kinds of fun and exciting ways (usually beginning with a well-intentioned `sudo pip install ...`). Homebrew suffers from this like other system package managers do, with the added pain that many macOS users expect Homebrew to do everything (whereas Linux users typically understand that they need `pyenv` or similar). PEP 668[1] helps a bit here by clarifying the responsibilities/expected behavior of system Python distributions, but at the cost of heartburn for some user scenarios (i.e. ones that depend on `pip install -U` and similar). [1]: https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/
cyberax 3y ago
> It seems most package managers were built with the assumption that you will stick to a single, officially sanctioned version of the language runtime and core libraries. The problem here is that it's impossible to build a coherent distro if you allow arbitrary mixing of versions, without parallel installability. I don't think it can really be solved in the general case.
- dagw 3y ago
  The first step is to separate system tools from userland tools. For example if system tools depend on python then they should be using their own isolate python and not the one that gets run when a user types 'python' on the command line. This way you can upgrade /usr/bin/python to 3.12 while /sbin/python (or whatever) can be locked at 3.8 to make sure important OS tools don't break. /sbin/python is not in the path of any user and only gets upgraded as part os a major OS upgrade.
  - matrss 3y ago
    Or you go the functional package management route and strip out these global paths entirely. nix and guix do this. Every package that needs python is built against a specific version of python (where a "version" is defined by its source code, compiler flags, toolchain versions, bootstrap toolchain versions, etc.; basically anything that can make the build result behave differently) and will only ever use that. Different packages can use different python versions. A system configuration can also choose to make a specific version available in the PATH, but it doesn't have to. A user environment can do the same, as can a project specific environment. All in one package management system.

by kijin 3y ago

woodruffw 3y ago

> Which is a reasonable assumption to make, for example, if the language in question is also used by system utilities in a traditional Linux distribution. You really don't want yum invoking the wrong version of python. Yep, this is the core reason: there needs to be a "system" distribution of Python, Ruby, etc. for packages written in those languages, and that distribution fundamentally needs to prioritize the interests of the package manager over "external" uses. This is particularly painful in the Python world, since using a "system" Python distribution for local development can break the system itself in all kinds of fun and exciting ways (usually beginning with a well-intentioned `sudo pip install ...`). Homebrew suffers from this like other system package managers do, with the added pain that many macOS users expect Homebrew to do everything (whereas Linux users typically understand that they need `pyenv` or similar). PEP 668[1] helps a bit here by clarifying the responsibilities/expected behavior of system Python distributions, but at the cost of heartburn for some user scenarios (i.e. ones that depend on `pip install -U` and similar). [1]: https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/

cyberax 3y ago

> It seems most package managers were built with the assumption that you will stick to a single, officially sanctioned version of the language runtime and core libraries. The problem here is that it's impossible to build a coherent distro if you allow arbitrary mixing of versions, without parallel installability. I don't think it can really be solved in the general case.

dagw 3y ago
The first step is to separate system tools from userland tools. For example if system tools depend on python then they should be using their own isolate python and not the one that gets run when a user types 'python' on the command line. This way you can upgrade /usr/bin/python to 3.12 while /sbin/python (or whatever) can be locked at 3.8 to make sure important OS tools don't break. /sbin/python is not in the path of any user and only gets upgraded as part os a major OS upgrade.
- matrss 3y ago
  Or you go the functional package management route and strip out these global paths entirely. nix and guix do this. Every package that needs python is built against a specific version of python (where a "version" is defined by its source code, compiler flags, toolchain versions, bootstrap toolchain versions, etc.; basically anything that can make the build result behave differently) and will only ever use that. Different packages can use different python versions. A system configuration can also choose to make a specific version available in the PATH, but it doesn't have to. A user environment can do the same, as can a project specific environment. All in one package management system.