5 ms·

This is the real legacy problem: Python comes from a world, where only one version of one packaged seemed the right way to do. I do not have a good idea, but o

This is the real legacy problem: Python comes from a world, where only one version of one packaged seemed the right way to do. I do not have a good idea, but other ecosystems evolved much more sane in the realm of packaging. While not ideal, Go has done a fairly good job - and the "module" operations are instant - which they should be.

1337shadow 5y ago
Ok but Go compiles statically, while you can do the same with pyinstaller, I don't think that's really comparable as we're talking about deployment right there.
- rizkeyz 5y ago
  Static binaries are a different story. Go has dependencies as any other modern language and they had a bad story in the past and have a better story today. Sketch for python: Create a ~/.cache/python/packages directory. Manage all dependencies there. Make the python interpreter "package aware" so that required dependencies are read off a file from the current project (e.g. "py.mod") and adjust "system path" accordingly and transparently. Or something along those lines. No extra tool, a single location, an easy to explain workflow (add a py.mod file, add deps there with versions, etc). I'm just thinking out loud, but it does not need to be hard.
  - 1337shadow 5y ago
    > Manage all dependencies there Are you saying "put the different version of every dependency you need in there if you have to"? Because I don't think package managers are ready for that, they usually like to have one version installed per package.
    - coldtea 5y ago
      >Because I don't think package managers are ready for that, they usually like to have one version installed per package. That's on them. Other language package managers can do it...
      - 1337shadow 5y ago
        Exactly, the whole topic is about easing the process for Linux distro packagers right?
goodpoint 5y ago
Go is terrible for distributions to package due to the poor versioning of libraries.
- goodpoint 5y ago
  Despite the downvotes, the argument stands: linux distributions are having a hard time handle the amount of tiny libraries and the conflicts in versioning and many maintainers voiced their concerns in the past years. The HN bubble can be amazing sometimes.
  - PeterisP 5y ago
    The point echoed in this discussion multiple times is that distributions should not handle the tiny python libraries and attempt to solve the dependency version issues, but treat an application with all its dependencies included as a single package. If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested, repackaged and rereleased for the update. This would cut down on the number of packages to be maintained, as the vast majority of python libraries would be exclude from the direct packaging process.
    - goodpoint 5y ago
      > If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested The burden of updating multiple copies of the same library across many packages grows exponentially and is simply untenable for distributions. If you can find an army of volunteers to do that, distributions would love their contributions. This hasn't happened in the last 20 years. I'd love to be proven wrong.
      - PeterisP 5y ago
        Since simply updating the dependency can easily break the resulting package, this need to re-test is not something that can be avoided by making some other choice of packaging e.g. the current one - it's not adding a new burden, it's acknowledging that it already exists (indeed, IMHO much of what the original article complains about). If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.

1337shadow 5y ago

Ok but Go compiles statically, while you can do the same with pyinstaller, I don't think that's really comparable as we're talking about deployment right there.

rizkeyz 5y ago
Static binaries are a different story. Go has dependencies as any other modern language and they had a bad story in the past and have a better story today. Sketch for python: Create a ~/.cache/python/packages directory. Manage all dependencies there. Make the python interpreter "package aware" so that required dependencies are read off a file from the current project (e.g. "py.mod") and adjust "system path" accordingly and transparently. Or something along those lines. No extra tool, a single location, an easy to explain workflow (add a py.mod file, add deps there with versions, etc). I'm just thinking out loud, but it does not need to be hard.
- 1337shadow 5y ago
  > Manage all dependencies there Are you saying "put the different version of every dependency you need in there if you have to"? Because I don't think package managers are ready for that, they usually like to have one version installed per package.
  - coldtea 5y ago
    >Because I don't think package managers are ready for that, they usually like to have one version installed per package. That's on them. Other language package managers can do it...
    - 1337shadow 5y ago
      Exactly, the whole topic is about easing the process for Linux distro packagers right?

goodpoint 5y ago

Go is terrible for distributions to package due to the poor versioning of libraries.

goodpoint 5y ago
Despite the downvotes, the argument stands: linux distributions are having a hard time handle the amount of tiny libraries and the conflicts in versioning and many maintainers voiced their concerns in the past years. The HN bubble can be amazing sometimes.
- PeterisP 5y ago
  The point echoed in this discussion multiple times is that distributions should not handle the tiny python libraries and attempt to solve the dependency version issues, but treat an application with all its dependencies included as a single package. If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested, repackaged and rereleased for the update. This would cut down on the number of packages to be maintained, as the vast majority of python libraries would be exclude from the direct packaging process.
  - goodpoint 5y ago
    > If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested The burden of updating multiple copies of the same library across many packages grows exponentially and is simply untenable for distributions. If you can find an army of volunteers to do that, distributions would love their contributions. This hasn't happened in the last 20 years. I'd love to be proven wrong.
    - PeterisP 5y ago
      Since simply updating the dependency can easily break the resulting package, this need to re-test is not something that can be avoided by making some other choice of packaging e.g. the current one - it's not adding a new burden, it's acknowledging that it already exists (indeed, IMHO much of what the original article complains about). If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.