3 ms·

Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant

Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable. These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware. In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.

geerlingguy 4y ago
Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.
- mikepurvis 4y ago
  I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
  - wallmountedtv 4y ago
    I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.
    - mikepurvis 4y ago
      Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.

geerlingguy 4y ago

Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.

mikepurvis 4y ago
I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
- wallmountedtv 4y ago
  I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.
  - mikepurvis 4y ago
    Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.