Hacker News new | ask | show | jobs
by WhyNotHugo 1671 days ago
So there's a few types of projects you can write in Python:

1. Server applications that run in a dedicated environment.

2. Tools you write and run just on your machine (or some virtualenv, whatever).

3. Redistributable cli or desktop applications which end users will install and use.

For the first two types, you should never have any issues with Python and its dependency situation. You pin everything, and that's it.

For the third kind tho, it's complete pain. Different distros ship different Python versions, so you need to support all of them. You also have to consider that dependencies can't be an EXACT version, you have to support a range of them, and a variety of combinations.

And then, one dependency has a version that works in Python3.6, and another for 3.9. But they had an API change, so which one do you use? It'll break for half your users either way. Of maybe just put some `if version <= 3.6` all over the place, like we did during the py2->py3 transition?

1 comments

#3 is the exact case where you also want to just pin everything. For an end-user desktop application, you ship a properly tested bundle, instead of trying to support all the different versions; as the end-user (unlike a developer using a lib on their own machine) should not ever have to interpret compatibility issues and should get a package that's been tested to work as a whole.

If a distro ships python 3.6 and the app wants to use 3.7, then the end result must include python 3.7 as well, either by distro being capable of having both versions at the same time or the app needs to ignore the distro-python and ship its own version in the package.

> For an end-user desktop application, you ship a properly tested bundle, instead of trying to support all the different versions

Good luck trying to get such a bundle packaged into any mainstream distribution.