[cdent]

I'm always confused by these sorts of posts because they happen often so there is clearly a problem but for some reason I've never had much of an issue. I've been using and developing with Python for about 15 years. In that time I've worked on Python projects large (OpenStack) and small (gabbi) and taken over maintenance for some old standbys (wsgi-intercept, paste to name two). Dealt with the 2->3 transition. Released a whole bunch of things to PyPI and relied on far more things that I've pip installed from there. It's been fine.

I don't know what I'm doing differently.

[WhyNotHugo]

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?

[PeterisP]

#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.

[WhyNotHugo]

> 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.

[1337shadow]

OpenStack uses pbr which they created and which is pretty cool. I use setupmeta for the same purpose but could have used pbr.

https://github.com/openstack/pbr https://github.com/codrsquad/setupmeta

[sufehmi]

Just scroll down - loads of horror stories shared by others