Carlton GibsonSep 1, 2025
I know I live on a different planet to many but, the only Python packaging problem I actually have is when I need to use two different versions of the same package at the same time. Solve that and we'll talk. #python
Show threadTin Tvrtković

@carlton the thing about multi-version support that I always wondered about it... If this feature existed, it would mean no global state, right? Since global state is often kept at module-level, and there would be several (maybe many) copies of each module.

"Ooh I have to configure structlog 1.2, 1.3 and better not forget 1.4" ;)

Sep 1, 2025 at 9:07amPhanpy Dev
Show threadCarlton GibsonSep 1, 2025
@tintvrtkovic Yeah, I'm sure it's not an equilibrium position, but namespaces are a thing, and slow-dependency's internal use of util < new-hotness blocking use of util == new-hotness continues to be a pain.
Show threadDavid ZaslavskySep 3, 2025

@tintvrtkovic @carlton Global (in the #Python sense of "global", i.e. module-level) state is kept in the module object in memory, but once that module object has been loaded from a file, it exists independently of the file it came from. So if you did load multiple different versions of a package, they'd all correspond to different module objects in memory, each of which could have its own global state. Heck, even with just one version of a package, you could load some module from that package a hundred times and get a hundred different module objects in memory, again each with its own individual global state.

This is kind of what the importlib.reload() function does, although IIRC it also tries to mix the original and reloaded versions of the module in a way that is supposed to make sense if you don't care about the old module. To get a true fresh and independent copy of the module object you'd have to use other importlib functions.

Show threadDavid ZaslavskySep 3, 2025
@tintvrtkovic @carlton Anyway, back to the point... I think the reason #Python 's packaging tools normally won't install multiple versions of the same package in the same environment is more to avoid confusion more than anything else. Like, when you import a module from the package, which version does it come from? If part of your code needs one version and another part needs a different version, how do you identify in each part of the code which version of the dependency it should import from? And how do you express version constraints on a sub-package level? (like, if source_file_a.py in your package needs dependency-X>=1.2,<2, but source_file_b.py needs dependency-X>=1.6,!=2.0.1,<3) You can write custom code to solve these problems, but I suppose the developers of the packaging standards and tools looked at how it's played out in the past and decided that it's so rarely useful and so potentially confusing that it's not worth supporting in the default setup.
Show threadDavid ZaslavskySep 3, 2025
@tintvrtkovic @carlton ...that was much more than I meant to write when I started out 😛 but I dunno, hopefully you find something useful in all that
Show threadCarlton GibsonSep 3, 2025
@diazona @tintvrtkovic Quietly muttering “DON’T GET NERD SNIPED” to myself. 😉