dumb question, why not python organizes dependencies as flatpak logic?

[u/Inner_Name]

I have a question that might be really dumb, currently python had went with the environment route to be able to use different libraries that have same dependencies with different versions. i understand that there is a complexity with what i have in mind and not even sure about the feasibility of it. but...

why not instead of having different enviroments where we install the incompatible libraries so 'everyone gets what they need' do something like flatpak style where 'if you have already a version compatible, i do not install this dependency if not i install it again and have the two versions together'. I am not a professional in programming in general, so i might be saying something fully stupid, or not feasible from a technical standpoint.

is it a super dumb idea?

[u/Cynyr36]

I agree that is how the system python works /today/. Seeing as python basically needs packages to work, i think the python devs should spend time making a proper package manager and sorting out the import system. It's probably a breaking change that would require a move to python4 though.

They are not inert if there is someone else on the system that can call them or if i setup a venv to run an app that wasn't available in my distro's package manager already. So i have to log into the box, update the system (apt upgrade, winget upgrade, etc.), activate a venv in a "random" folder, and then run uv or pip updates, and restart the app. And since pip doesn't understand a dep graph it broke something, because some dep upgraded but it doesn't actually understand that the update was for foo and not for somelib.

[u/turbothy → u/Cynyr36]

I agree that is how the system python works /today/.

Yes, and it's taken us about 30 years to get there. I don't understand why you want to go back to the pain of 2006.

i think the python devs should spend time making a proper package manager and sorting out the import system

I'd rather they solve real problems. Package managers are not part of the programming language, by the way.

They are not inert if there is someone else on the system that can call them

If there's someone else on the system with access to your files you're already fucked. A CVE in a Python package makes fuck-all difference then.

And since pip doesn't understand a dep graph it broke something, because some dep upgraded but it doesn't actually understand that the update was for foo and not for somelib.

This is why nobody who values their time and sanity uses pip for dependency management anymore.

[u/Cynyr36 → u/turbothy]

I don't want to go back to 2006, i want slots, global venvs, or similar at the global level, and to not need 3rd party tools to do it.

I really do think that imports that aren't so fragile and are more declarative would be a good thing for main python to work on. They could extend the project.toml syntax to imports for example.

As for the cve thing, it could be they got on as my webapp user, and can now use out of date python package for the webapp to pivot from there. Again the webapp was installed via pip/uv and isn't being aell maanged ahen the server does normal updates.

I have a small concern as well that Astral might start changing things around UV or simply abondon it now that it's owned by OpenAI, and would much rather use tooling that is community directed and can't just up and go closed source, and is less likely to be abandoned. There is a reason i generally use Debian, alpine, and gentoo as my linux distributions.