Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development.<p>This also applies to many others programming languages which have their own packaging systems.<p>While python packaging is indeed messy the needs of traditional linux distributions are by far the least important. Python packaging needs to better serve the needs of python developers, not those of sysadmins.<p>Having a "linux distro" interpose itself between you and your libraries is a fundamentally broken system not worth fixing. All decisions related to dependency choices fundamentally belongs with upstream.
Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people.<p>But as a rant this, like most of the ‘but just fix it’ rants, fails to acknowledge the hugely diverging needs of different users. I could not live without conda, since it’s the only sane way to get a working recent geospatial stack. Others need to run embedded environments, or portable ones, some need long term stability while others need bleeding edge packages that haven’t been released yet. Solving for a single case is straightforward; solving for all of them , not so much.
This is my decision flow and I rarely have an issue:<p><pre><code> Are you the end user of the Python code?
Yes -> Is available in your distro?
Yes->Use package manager
No->Use pip install in user mode
No -> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there
</code></pre>
Some extreme use cases may benefit from anaconda, but personally I've never needed to use it. My only pain point is dealing with legacy code that relies on PYTHONPATH. Nothing good ever starts setting PYTHONPATH.
Yes, python packaging is a mess.<p>And agreed, there are two separate use cases: development and using the software.<p>But, are distros creating too much work for themselves by trying to package every itty-bitty python library (and for that matter, every npm library)? Are distros doing anything more than scanning CVE databases with the library versions, or are they _actually_ auditing the versions they choose? (Not that there's much choice, since python also has a shitty story when it comes to backwards compatibility; if you're going with 3.10, there's possibly only one version of a given library that will work.)<p>Java has a commonly used "fat jar" approach which rolls up all dependencies into a single file. It's excellent. In the python world, this doesn't exist, because virtualenvs aren't portable. If that can be fixed (perhaps a specific section in requirements.txt that captures anything that needs to compile C for the platform) then a distributable virtualenv would become possible. Distros would then scan the application for vulnerabilities (via requirement.txt's manifest), build the distributable-virtualenv, and ship _that_. Python library maintainers don't have to do anything different (except, of course, use the standard way to declare dependencies).
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.<p>I don't know what I'm doing differently.
Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv.<p>What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them to `python`.<p>If I would get to redesign package management (both for Linux distros and for languages), I would have <i>one</i> package manager that installs everything into a global package cache, and then pick the correct version of libraries at run time (for Python: at import time). Get rid of the requirement that there is only one stable (minor) version of a package in the distribution at one time. This has become unworkable. Instead, make it easy to get bleeding edge versions into the repositories. They can be installed side by side and only picked up by the things that actually use them.
I am not one to install python packages using my distro's package manager, but I totally agree with the sentiment that we need a more standard build/dependency management system in python. I like poetry, and I think most people are heading that way, but it doesn't seem to play super nice with pyenv (which is a critical tool) a lot of the time, and I think that a first party endorsement of the "one true build system" a la golang or rust would be a huge step.
> Every one of these package managers is designed for a reckless world in which programmers chuck packages wholesale into ~/.pip, set up virtualenvs and pin their dependencies to 10 versions and 6 vulnerabilities ago, and ship their computers directly into production in Docker containers which aim to do the minimum amount necessary to make their user’s private data as insecure as possible.<p>Is this any different from any other programming language ecosystem? Is Python really doing worse than Node, Ruby, Perl, Lua, Go, or Haskell in this regard?<p>Python files go in `/usr/lib/pythonx.y`, Python finds said files, programs run.<p>Yes, Python build and packaging <i>in general</i> is messy. But I am curious why, specifically from a distro perspective, it's any worse than anything else.
Am I the only one that is not having issues with python and distributions in general?<p>I get all my dependencies from Debian and they all work, when I need something that is not yet packaged, I use pip.<p>What are people doing to get all this issues? I don't understand...
My usual approach is to let the distro install the packages it wants and then, for each thing I'm working on (I sometimes write Python code for a living) can have a separate environment with different module versions. This makes sense when my artifacts are deployed via Docker images that are generated with `pip install`, but not as much if you plan to install them in your machine. The only thing I build like this for public consumption is pip-chill, which is not intended to be used with the bare Python environment of the distro (I probably should add something that makes it refuse to install that way).<p>Even when the things are not Python-based, I often use a virtual environment, managed with virtualenvwrapper (installed on the distro level). One example is a Terraform config that relies on some Python tools to manage deployments - the Python tools are local to that virtual environment and not usable anywhere else.<p>If I need to develop something that'll need to run with the distro directly (something that could be distributed as ditro packages) I'd use a virtual environment and tailor the package versions in requirements to the ones available in the distro. This way, multiple distros can be addressed with multiple environments pointing to the same source directory and multiple requirements files for tests.
> What is it about Linux distros that makes our use-case unimportant? Have we offered no value to Python over the past 30 years?<p>Indeed you haven't. Worse, you've actively damaged Python's efforts to improve. I mostly work on the JVM these days, and I think one of the main reasons dependency management there is so gloriously simple and effective is that the Debian packagers weren't around to fuck it up.
This is a very weird post to read, as someone who does (occasional) distro Python work - I feel like Python absolutely is listening to us! It's just that it's hard work, and distro packaging is mostly done by volunteers, and there are a whole lot of things to work through.<p>Here's some work I and others did earlier this year, which I thought was a great example of folks from the core Python packaging world and folks from distros working together: <a href="https://www.python.org/dev/peps/pep-0668/" rel="nofollow">https://www.python.org/dev/peps/pep-0668/</a> See the massive table of use cases for all the things we had to think about.<p>You might note that one of the things it needs is additional participation on the Discourse thread from the authors (like myself) and from other distros. Again. It's mostly work done by volunteers, and there's a lot to work through. There's no magic to it.<p>I can tell you that the following (from TFA) will absolutely make things worse for distros, though:<p>> <i>I call on the PSF to sit down for some serious, sober engineering work to fix this problem. Draw up a list of the use-cases you need to support, pick the most promising initiative, and put in the hours to make it work properly, today and tomorrow. Design something you can stick with and make stable for the next 30 years. If you have to break some hearts, fine. [...] These PEPs are designed to tolerate the proliferation of build systems, which is exactly what needs to stop. Python ought to stop trying to avoid hurting anyone’s feelings and pick one.</i><p>If you want the PSF to fund some engineering work on its own that it can finish much faster than any volunteer packager can even read the proposal, break some hearts, stop proliferating build systems, and hurt people's feelings, they will absolutely do that and say "Distro packaging is not supported, we only support virtualenvs. Users should make virtualenvs. Distro software should ship virtualenvs. Installing a Python package systemwide is meaningless." That's clearly the best-supported option right now, and it's a surprisingly technically defensible answer, but it's not going to make you happy.
I have a lot of (possibly controversial) issues about this post, for various reasons:<p>- Debian/Ubuntu Python packaging is actually pretty comprehensive, and Ubuntu LTS ships with reasonably updated (although admittedly not latest revision) third-party packages that are usable out of the box, and that I could just list in Ansible to have usable environments spun up.<p>- Python packaging is hardly a mess. I have been using pip for ages without any issues other than forcing wheel downloads for unusual distros (like Alpine, where musl makes it chancy to use some low-level stuff). But if you're on a mainstream distro with modern pip, wheels just work.<p>- If you're not on Linux (or not on the mainstream), pyenv also just works. I have been using it across several years of macOS releases without any significant issues other than knowing to pass it the required build flags to build out the Cocoa bindings here and then (which is easy to do with the brew pyenv).<p>And, finally, I'm constantly shocked at the number of people who just don't get virtualenvs, or who don't know how to switch python interpreters by using environment variables.<p>I've never looked back, and they were instrumental in bridging the gap between 2.7 and 3.5 while I converted some code across (I never really found that the switch to Python 3 was as dramatic as many people made it, perhaps because the code I handled worked after a single pass with 2to3 and minor tweaks).
Distro maintainers say that language ecosystem packaging makes it hard for them.<p>Language ecosystem packaging maintainers say that distro package managers make it hard for them.<p>The year is 2021 and there is no work towards synthesis. It will be endless, fruitless yelling from each side.<p>Maybe 2022 will bring change. I'm not holding my breath.<p>To anyone who finds themselves on a single "side" in this argument: if you have ever said "why do you need to do that" as an accusation instead of with curiosity, you exemplify the problem.
I've had success restricting myself to Python packages provided by the OS (Debian) in production. The only down-side is there is only one Python (well, 3.* or 2.7) against which to test, so I drop back to a pip install of the same packages for CI, and that's where 90% of my Python pain comes from, every maintainer of every Python infrastructure package feels entitled to shout "DEPRECATION, do THIS, do THAT, use THIS" at me. It's ill-mannered and unpleasant.
I think there is an increasing trend for developers to get confused between their tools and their output.<p>These are your tools:<p><pre><code> * pip
* pip-tools
* pipenv
* poetry
* virtualenv
* venv
* setuptools
* pyenv
* requirements.txt
* etc.
</code></pre>
These are your outputs:<p><pre><code> * wheel (binary),
* tarball (source).
</code></pre>
The tools in use are completely irrelevant and only add noise to the discussions around packaging. So what actually is the problem here? Are projects delivering broken outputs (ie. bad packages)? Are they not delivering outputs at all? Those are real problems but pointing at the number of tools that exist is not helping.
> pin their dependencies to 10 versions and 6 vulnerabilities ago<p>That is the real problem IMHO. Most python users like to pin dependencies so that "their program don't break", and that's also the reason why so much effort is put in what they call "correct" dependency resolution resulting in the creation of new python package managers that all do "more correct" dependency resolution and make programs "break less" and at the same time require less efforts from the maintainers to actually maintain their code by doing dependency upgrades. And then one day you want to upgrade a dependency and you realize you're 10 releases behind on 10 dependencies, and what was supposed to be a quick maintenance task is now 100 maintenance task.<p>If you don't pin, your program will break one day or another, a user might open an issue with the traceback, or, your program will break directly in CI where you will see the traceback. Upgrade it, or contribute to the dependency, but just go ahead and fix it, instead of being defensive and trying to have dependency resolution that "doesn't break". At the same time you'll be adopting the actual practice of "Continuous Integration", of your dependencies, which has a better cost/benefit ratio.<p>I always avoid pinning dependencies, I try to make pip just install the latest version of everything, I am willing to contribute upgrade fixes to any Python package I use, but some dependencies do pin which breaks my own aggressive Continuous Integration practice, heck, I'd even need an option for pip to ignore version resolution at all so that I can make all my contributions to upgrade everything I use. I even remember when I had CI test matrix with all combinations of versions of everything, I don't do that anymore, I just support the latest of everything, we can always have the latest python with containers anyway so that's not even a blocker anymore. If you're not a "techbro using containers", it'd be fine too because you should then be able to make your distro packages at any point in time and expect all of them to work together, minus the delta of the handful of upgrades that are pending to release here and there.
Currently my workflow when starting a new Python project is:<p>* Create a new conda environment with the minimum python version I need to support.<p>* Use poetry to install dependency<p>* Package the production build into container image for deployment.<p>The only problem I have is sometimes Poetry choke on compiling libraries with C-dependency, luckily most libraries provide binary wheel now.
The day packaging for distros will be easy, we will use it. Right now, making a deb is hard. Isolating 2 projects with different deb verions is hard. Distributing debs is hard. Upgrading your OS but not your python debs is hards.<p>Then rinse and repeat for red hat, arch, nix, mac and windows ?<p>Yeah right.
As a "self taught and still learning developer-lite", I love the python language, but the ecosystem drives me nuts. I feel a lot of the pain expressed in the article, and it pretty much speaks to my current conclusion of "I'm trying to do things the 'right way' but there doesn't seem to be a 'right way'".<p>I've seen a few comments here about how Nix/NixOS fixes the whole python binary/library mess, but I'm having trouble understanding how. Does anyone have any insight to share about that?<p>Additionally, the whole thing kind of makes me want to move away from python wholesale. I was wondering if there are other languages that are great general languages like python that don't suffer from this whole packaging and versioning mess. Ruby? Go? Something else? I'm looking for something high level, somewhat easy to learn, and with good library support for things like working with databases and tabular data. Though I don't know much about them, I just feel like I don't want something like Java or C++ or anything like that. I want to "get things done" and not have to worry about tons of boilerplate or working at really low nitty gritty levels.
Interesting take. I use Python daily and virtualenv is really good for our use cases (running CI/CD, testing installation and running in production in a container). I am not experiencing too many problems with pip + venv. We also maintain our own libraries and even those were relatively easy to set up. Mypy and yapf also helps to maintain a style and type correctness (do not pass in None accidentally).
Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis?<p>Our project gets a few issues opened by distro maintainers who have trouble with some part of their build process. Is it really worth our project maintainers time to help troubleshoot esoteric build processes when we already provide source, wheel, and conda distributions?
The OP mixes together different tools used for different causes.<p><pre><code> * setuptools/pip/poetry is package managers
* egg/wheel/? are package formats
* venv/conda are environment to isolate from the OS
</code></pre>
another degree of complexity is added by the OS: their package managers and ability to install as root vs under user. But in any layer, there's not much to get confused.<p>Over 12 years with Python the only serious change I saw was setuptools (was it named like that?) => pip in 2011. The only serious issue I saw was when I installed with several managers (OS, setup.py, pip) and/or as root/user. That got solved in 15-30 minutes after checking the imported package __path__, and cleaning things up.<p>Teaching people at courses, I saw people who struggled the most never checked anything: doesn't work? They'd try installing harder, or just re-ran things. But they never checked where the packages were installed, and where from they were imported.<p>Otherwise, I came to following simple rules:<p>1) python & ipython are installed via an OS package<p>2) packages that have to be executed like jupyter may be installed as root, or user; just never install both.<p>3) all other packages are installed as user. Computers are personal, and I almost never execute things as root, nor have other users.<p>Maybe being able to examine sources of errors was why I didn't feel it was so hard? I'm not a sysadmin, nor a hardcore programmer. It's just I got used to check paths and read error messages attentively.<p>This does not mean it's easy, I wish things were simpler, there were less ways to do things, but the OP exaggerates things as if there's a thousand of tools.
The PSF won't fix it, its members are the problem. Dozens of people profit from useless churn that results in billable hours, and they actively purge anyone who opposes.<p>Switch languages, this is a lost cause.
Blaming Python vice Linux distros isn't important. The implicit agreement that a system Python will be set up in a certain way, with a certain version etc is fragile. Programs and processes included with a Linux distro expecting a certain Python set up is a problem - it's making assumptions about system state. Python doesn't include tools for managing versions, dependencies, and standalone programs. Linux distros use programs depend on it despite this.<p>At the core of this is implicit cooperation between system programs, third party programs, and users. This concept underlies a common frustration with Linux: It works reliably out-of-the-box, but customization and installing programs introduces problems.<p>I wrote a Python dependency and version / installation Manager in Rust to help deal with this sort of thing, as well as related issues like dep conflicts between Python projects.
The flexibility the author decries is one of the strengths of the ecosystem. Oh, things don't work for datascientists on Windows? Here, use conda. Bunch of different webapps on same server? Use venv. And so on and so forth, every niche will use what works best for them.
This is one reason Go has become so popular. If Python weren't such as mess, people could look past its poor performance, but combine that with the installation and dependency issues and it's just too much.
Python's trend of "reinvent it yourself" engineering leads inexorably to a sprawling mess of duplicated and incompatible projects. The source of this problem is Python's lack of "lead by example" on the topic of DRY code / implementations.<p>With Perl modules (like Python packages), the intent is to never have to rewrite them, but to make them so generic that they are just extended by new modules (that inherit the old modules) to gain more features. Their naming convention reinforces this intention, with "Net.pm", "Net/IMAP.pm", "Net/IMAP/SSL.pm", etc. Each one of those files can be uploaded to CPAN by a completely different developer, without having to completely re-write all the base stuff from scratch. You can already do that with Python, but because everyone names their packages "fizzbaggy", "unclib2", "OtherThingHere", etc, there's no sane convention that clearly tells you what this thing is, what it does, or what it depends on.<p>The end result of all that is a nightmare in terms of regular users figuring out how to install and use most Python scripts, packages, and tools. This is part of why Go is so popular now: no need for an engineering degree just to run a Python program!<p>I do not believe there is any way for Python to re-invent itself and suddenly become less sprawling or confusing. The shift would be too huge and take too long.
It seems a bit weird to criticise lots of people for trying to solve the dependency problem. I know lots of people hold up npm as the standard. Npm came out around 10 years ago, Node around 12. Both of which had the benefit of hindsight at how the problem had developed for other languages. Python came out 30 years ago and pip came out 20 years later. Of course there is a lot of stuff left behind. What do people suggest, a breaking change, maybe? Python 4?
Linux should exert his "Linux" trademark rights by putting a representative from each of the major distros in a room, telling them to come to an agreement on a single packaging and filesystem layout for Linux, or they can no longer call their precious snowflake Linux. To me, this more than anything has hampered Linux adoption: there are too many versions of it.
If i understand correctly, this is the kind of problem Flatpak and Snap can solve. As a developer, relying on a distro's provided packages just seems too cumbersome - there are 10s of distros all with different versions of your dependency and different packaging systems. I guess the only way to distribute a Python application today that works across distro would be to basically build a single application that works simultaneously on many different python versions, not to mention the shared C libraries and other system software used by important Python packages. What do you do if you use psycopg2 X that needs libpq-dev version between 1 and 2 but the distro bundles in an incompatible version of libpq-dev Y? You have to now support 2 versions of libpq-dev across the project, and all dependents of libpq-dev such as psycopg2?<p>The shared dependency model is just too complex to work with, and we have enough disk space that its not really necessary anymore. Sandboxes seem like the way to go.
I got introduced to pip and virtualenv when I started coding in python in 2013-14.
Except for the system/3rd party python and python2/python3 confusion a couple of times, I've been able to set up many projects at multiple companies that quite a few people have worked on over the years without any problem just using pip and virtualenv.
Somehow every time I searched about a better way of doing it, the new tools looked more confusing that the existing one. And since the existing ones keep working very well, I haven't had any incentive to move to any other tool that does even more magic under the wraps, in the name of making things simpler, because when the required conditions aren't met, these tools simply tend to give up.
So I just setup the virtualenv with the appropriate python version and then use pip to install python dependancies. Projects have varied from webservers to computer vision and forecasting. And have not faced any issue till date.
> I manage my Python packages in the only way which I think is sane: installing them from my Linux distribution’s package manager.<p>Actually, this is <i>not</i> sane.<p>If you have any Python dependencies, you should always develop and deploy your code using virtualenv, never by installing packages into the system Python!
A suggestion:<p>1) If your distro requires Python, don't put it on the path. Refer to it another way if you need it, e.g. have a distroname-system-python package you upgrade at your own cadence.<p>2) That's it. Then developers can install Python how they like, and it's (probably) all fine.
The more I see package systems that don't work the more I think Java from all the criticism got it right. Between always enforcing backward compatibility to being explicit about where to look for dependencies everything just works.<p>Of course you still have problems on how to declare those dependencies and resolve upgrades but a code you compiled 10 years ago will probably still work today. Compare that to Python or even worse nodejs and it's bonkers the amount of context you have to be aware of just to make your code that worked fine 2 years ago build again on the current tool chain.<p>edit: typos
>I
What is it about Linux distros that makes our use-case unimportant? Have we offered no value to Python over the past 30 years? Do you just feel that it’s time to shrug off the “legacy” systems we represent and embrace the brave new world of serverless cloud-scale regulation-arbitrage move-fast-and-break-things culture of the techbro startup?*<p>The thing is, people in development wont use the distro python (but different installs, pyenv, etc), and people in devops wont use the distro python either...<p>So, what values does it offer to whom? Except maybe scripting for sysadmins?
> Every one of these package managers is designed for a reckless world in which programmers chuck packages wholesale into ~/.pip, set up virtualenvs and pin their dependencies to 10 versions and 6 vulnerabilities ago, and ship their computers directly into production in Docker containers which aim to do the minimum amount necessary to make their user’s private data as insecure as possible.<p>That's pretty sobering look at the state of affairs.
There actually exists a solution to unite the distros packages with the developer ones: Nix (or GNU Guix, if you prefer that).<p>And yes, both 'are' a Linux distribution too.<p><a href="https://nixos.org/" rel="nofollow">https://nixos.org/</a>
<a href="https://guix.gnu.org/" rel="nofollow">https://guix.gnu.org/</a>
The success of Python and Go shows that people don't care as much about what distributions maintainers feel is "quality packages".<p>The scale and quantity of software being developed is just too much for traditional Linux distributions approaches. I personally rely on Debian to know that most of the packages I use are reasonably secure. But often I need to sacrifice flexibility and bleeding-edgedness.<p>And it couldn't be otherwise. There are 339,267 projects on PyPi.org. I bet a good percentage of these are riddled with security flaws. But people use them anyway. How many distro maintainers would you need to handle this workload? Is it worth it? Does anyone care?<p>It looks like people care much more about experimentation and speed of development than stability, security or coherence and cleanliness of the solution. The author seems to feel this is wrong from an engineering (or even moral?) perspective.<p>I am also uncomfortable when I have to deal with Python and I have my own favourite few tools... but perhaps if Python users really wanted a single solution then it would already exist.<p>If you are instead convinced that there is this need and no adequate solution, then congratulations, you just found a gap in the market. Go on and do better than everyone else before you. Relevant XKCD comic is already in the article...
I once attempted to install a program that was distributed via pypi (pip was the only way I could install software on that server). The shebang in the script file was #!/bin/python. Thats python2 on most Linux distros and so it couldn't run
And then you’ve got the MS store that just hijacks any calls to python completely even if you installed it separately<p>Debian apt installs with using python3 and specifying pip as a module call is the only thing keeping me sane
we need one, only one build system, not many. Feels like atm python is a bit shattered around like c++<p>Using JS or rust seems easier with the unified build system.
If you avoid placing packages in the distribution's system Python (by using a venv) <i>and</i> if you aren't using some outdated distro version, your Python should be good enough. You must write backwards compatible code anyway, if your application is to last more than six months.<p>It is not the end of the world to be using one or even two minor versions older than the current Python version. New features must be implemented in your code and relying on bleeding edge features of your language (in production code) is outright bad design.
If the core Python developers like to experiment and break their language, you are best to avoid jumping head first into that mess.<p>TL;DR:
Keep your requirements conservative. You are not bewilden to the Python core developers, your target are your users.
So here's a suggestion to shoot down.<p>The biggest insight in software dependency management is that applications and libraries are different. Both have dependencies but they sit at different places in their dependency graphs.<p>A library can be used together with other libraries and so cannot pin its own dependency versions (if all libraries did so there would conflicts everywhere) but instead can only specify constraints on its dependency versions (eg >=1.0.0).<p>An application sits at the front of the dependency graph. Nothing depends <i>on it</i>. It can therefore lord it over its dependencies, pinning everything in the graph to specific versions. This only works, though, if it doesn't have to share an environment with other applications and unrelated libraries.<p>Systems like poetry (akin to npm or cargo) allow a "lock file" to be generated with pinned versions for all dependencies, satisfying all the version constraints. Applications must commit this to revision control, libraries can if they want (should IMO). This is great as it allows CI and other devs to use consistent versions.<p>The missing piece is that for an application, the lock file <i>should also be used for deployment of the app</i>. If you can ensure that an application is installed in an isolated environment with the dependency versions from the lock file (i.e. that the app was tested against) then a lot of the pain disappears.<p>So, the suggestion:<p>* Add support to standard python distribution (wheels, pypi, etc) for application packages to specify (in addition to ordinary version constraints) a pinned set of "preferred" dependency versions.<p>* Have tools like poetry/pipenv set these to the lock file versions.<p>* Allow a notion of "application packages", which are required to have this information in.<p>This should work very nicely with tools like pipx that deal specifically with python <i>applications</i>. The relevance to linux distros is that linux distros also should only be packaging applications (and their dependencies). Developers using libraries should be managing them with tools like poetry/pipenv, not the system package manager.<p>If the system package manager could install python applications in their own isolated environments along with their pinned dependency versions, most of the pain goes away for distro maintainers. If an application isn't working with the dependency versions it has specifically asked for, it's a clearcut problem with the application as published, and needs to be fixed upstream.<p>I realise this would be a significant change for package managers, but I think the same model makes sense for other languages with similar tooling and at least some of the work should only need to be done once.<p>Go on then, tell me why I'm wrong :-D
> I manage my python packages the only way a think it is sane: by using my Linux distro package manager.<p>Your honor, I have no more questions for the alleged victim. <drops mic>