7 ms·

People always get up in arms about this, but as someone who has used Python as her daily driver for years it's really... never been this serious of an issue for

People always get up in arms about this, but as someone who has used Python as her daily driver for years it's really... never been this serious of an issue for me? I have used virtualenv/venv and pip to install dependencies for years and years, since I was a teen hacking around with Python. Packaging files with setup.py doesn't really seem that hard. I've published a few packages on pypi for my own personal use and it's not been too frustrating. A lot of the issues people have with Python packaging seem like they can get replaced with a couple shell aliases. Dependency hell with too many dependencies becomes unruly in any package manager I've tried. Is the "silent majority" just productive with the status quo and getting work done with Python behind the scenes? Why is my experience apparently so atypical?

philwelch 6y ago
As an individual that probably works just fine. In a team setup, it takes a lot of training and effort for everyone to consistently follow a manual pip/venv workflow, so it becomes valuable to minimize and standardize it.
- throwaway894345 6y ago
  Especially if you have to deploy to production and you want fast, reproducible builds, or you don't want to run a bunch of tests for things that haven't changed.
olalonde 6y ago
To be blunt, maybe you just don't know what you're missing out on? Of course, Python's package management system works and is merely an annoyance to those of us who are used to more modern package managers. By the way, your comment reminded me a of this classic: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 :)
- madelyn 6y ago
  I mean, possibly? What's considered the gold standard in package management these days? I use yarn for managing javascript dependencies and do a lot of work with Cargo too. The community seems to love both these tools outside of slow compile and install times.
  - throwaway894345 6y ago
    Cargo is my ideal, but really anything that doesn't make me manage virtualenvs or take 30 minutes to resolve dependencies. Note that "managing my own virtualenvs" is tricky because you have to make sure everyone has all of the same versions of the same dependencies in their virtualenv across your entire team (including production). I'm sure there are workflows that allow for this (probably with some tradeoffs), but we haven't figured it out. For a while we used Docker, but performance degraded exponentially as our test base grew (Docker for Mac filesystem problems, probably). Eventually we settled on pantsbuild.org which has a lot of problems, is super buggy, no one can figure out its plugin architecture, etc but as long as you stay on the happy path it generally works okay which puts it in one of the ballparks between any other Python dependency management scheme I've tried and Go/Rust/etc package management.
    - stuhood 6y ago
      Great experience report: thank you! Wanted to point out that the Pants project has been focusing on widening that happy path recently (...by narrowing its focus to Python-only in the short term), and is ramping up to ship a 2.0. This page covers some of the differences between v1 and v2 of the engine, and particularly its impact on Python: https://pants.readme.io/docs/pants-v1-vs-v2 https://pants.readme.io/docs/pants-v1-vs-v2 ... We're using Rust and haven't bootstrapped yet, so we also appreciate Cargo and think that there is a lot to learn there. We'd love feedback (via any of these channels: https://pants.readme.io/docs/community https://pants.readme.io/docs/community) on how to make it even better. Thanks!
      - throwaway894345 6y ago
        That’s great to hear. Is there any page that documents the architecture of pants? I understand build systems of various kinds quite well, but I can’t tease out the design philosophy behind pants, especially how the different target types / plugins end and the “core” begins. I’m going to dig into that 2.0 link though!
- d0mine 6y ago
  I've used a few (modern and not). Any package management system becomes uglier the more use cases it needs to support.
IshKebab 6y ago
I don't think your experience is atypical but I do think your acceptance of something that is quite awful is fairly atypical. It's also possible that you use Python on Linux, where it is at least tolerable. Try again on Windows.
- ssully 6y ago
  I develop Python exclusively on Windows (that then is deployed on Linux) and my experience is identical to the original poster. It's not a perfect system, but it's good enough and I have dealt with dependency management systems.
a_cool_username 6y ago
Let me start by saying: I love python, and I love developing in it. It's the "a pleasure to have in class" of languages: phenomenal library support, not too painful to develop in, nice and lightweight so it's easy to throw together test scripts in the shell (contrast that with Java!), easy to specify simple dependencies + install them. (contrast that with C!). That said... if you work on software that is distributed to less-technical users and have any number of dependencies, python package management is a nightmare. Specifying dependencies is just a minefield of bad results. - If you specify a version that's too unbounded, users will often find themselves unable to install previous versions of your software with a simple `pip install foo==version`, because some dependency has revved in some incompatible way, or even worse specified a different dependency version that conflicts with another dependency. pip does a breadth-first search on dependencies and will happily resolve totally incompatible dependencies when a valid satisfying dependency exists.[1] - If you specify a version with strict version bounds to avoid that problem, users will whine about not getting the newest version/conflicting packages that they also want to install. Obviously you just ignore them or explain it, but it's much more of a time sink than anyone wants. - In theory you can use virtualenvs to solve that problem, but explaining how those work to a frustrated Windows user who just spent hours struggling to get Python installed and into their `PATH` is no fun for anyone. Python's made great strides here with their Windows installers, but it's frankly still amateur hour over there. - Binary packages are hell. Wheels were supposed to make Conda obsolete but as a packager, it's no fun at all to have to build binary wheels for every Python version/OS/bitness combination. `manylinux` and the decline of 32-bit OSes has helped here, but it's still super painful. Having a hard time tracking down a Windows machine in your CI env that supports Python 3.9? Too bad, no wheels for them. When a user installs with the wrong version, Python spits out a big ugly error message about compilers because it found the sdist instead of a wheel. It's super easy as a maintainer to just make a mistake and not get a wheel uploaded and cut out some part of your user base from getting a valid update, and screw over everyone downstream. - Heaven help you if you have to link with any C libraries you don't have control over and have shitty stability policies (looking at you, OpenSSL[2]). Users will experience your package breaking because of simple OS updates. Catalina made this about a million times worse on macos. - Python has two setup libraries (`distutils` and `setuptools`) and on a project of any real complexity you'll find yourself importing both of them in your setup.py file. I guess I should be grateful it's just the two of them. - Optional dependencies are very poorly implemented. It still isn't possible to say "users can opt-in to just a specific dependency, but by default get all options". This is such an obvious feature, instead you're supposed to write a post-install hook or something into distutils. - Sometimes it feels like nobody in the python packaging ecosystem has ever written a project using PEP420 namespaces. It's been, what, 8 years now? and we're just starting to get real support. Ridiculous. I could go on about this for days. Nothing makes me feel more like finding a new job in a language with a functioning dependency manager than finding out that someone updated a dependency's dependency's dependency and therefore I have to spend half my day tracking down obscure OS-specific build issues to add version bounds instead of adding actual features or fixing real bugs. I have to put tons of dependencies' dependencies into my package's setup.py, not because I care about the version, but because otherwise pip will just fuck it up every time for some percentage of my users. [1] I am told that this is "in progress", and if you look at pip's codebase the current code is indeed in a folder marked "legacy". [2] I 100% understand the OpenSSL team's opinion on this and as an open source maintainer I even support it to some degree, but man oh man is it a frustrating situation to be in from a user perspective. Similarly, as someone who cares about security, I understand Apple's perspective on the versioned dylib matter, but that doesn't make it suck any less to develop against.
acomjean 6y ago
I think it depends on the use case. If I'm developing my own stuff my peen package management is fine. If trying to run various existing python programs to analyze biology data, I soon run into various problems. Is this a Conda?/ or can I use my Python environment? which version of python? will let me run the thing and what libraries do I need? This breaks in that version? Sometimes I feel that one kinda ok way of doing things, would be better than having 6 ways , one of which will suit my use case perfectly. This problem is not unique to python.
- dfsegoat 6y ago
  > Is this a Conda?/ or can I use my Python environment? Can you elaborate a bit there? I use conda because I like some of their features over standard virtualenv (being able to specify a python version when i create my venv) - but I've never had a problem running code in env's created by one vs. the other.
  - acomjean 6y ago
    Sometimes developers distribute their software via Conda installs, in those cases they sometimes don't provide instructions on running other ways (eg using the pyenv environment which is my default. ). I'm ok with this, but when conda fails as sometimes happens, it can mean some digging to get the install to work. I was thinking of my latest install, which was CRISPRESSO2, which installs via docker or bioconda... I was able to get it going, but it took a bit on some systems.. (Python 2.7 old libraries.. etc..) Docker didn't seem to work. I like virtual env, but sometimes I feel I have to have a new environment for each piece of software I'm running, which feels weird. https://github.com/pinellolab/CRISPResso2 https://github.com/pinellolab/CRISPResso2
franga2000 6y ago
When it comes to shipping Python server-side apps, Pipenv is a godsend. Before discovering it, I had 3 requirements.txt files (common, dev, prod) which I had to edit manually. This often meant forgetting to include something that I just installed and only finding out after a full round of QA. It also meant a separate couple of steps for full-tree dependency freezing which never worked quite properly anyways. Pipenv just....works. Dependencies are saved as I install them, I only have to deal with the top-level ones, but the whole tree is locked.
WD-42 6y ago
The only time I run into problems is when someone else is trying to use Conda. Then it can be hell trying to get their code running in standard pip/venv or vice versa. I'm sure Anacona filled a niche at some point, but we have wheels now, can we all just agree to stop using Conda? What value does it actually bring now that makes it worth screwing up the standard distribution tools?
- darkarmani 6y ago
  Isn't a conda environment just python installed into an isolated directory where someone can run pip? One can just run pip and pretend it isn't a conda environment.
  - WD-42 6y ago
    It's way more than that. Firstly, most Anaconda installations come shipped with libraries like Matplot, numpy, etc. So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py. Then there's the issue of Anaconda using it's own package repos, so even if you do manage to figure out what packages an Anaconda developed piece of software needs, you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs. Lastly, certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder. I get that it's convenient for scientists that just want to write scripts and have them work, but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs.
    - darkarmani 6y ago
      > So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py. How is that any different than using python.org python? You'd still be unaware of what versions to use. > you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs. That's way more of a problem with pip. You have no idea what versions a pip package is pulling in until install and then what binary actually gets installed depends on your compilers. > certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder. That's impossible unless one is actually copying binaries manually overtop of system binaries. You'd have to be root or use sudo to overwrite the system python manually. The whole point of isolation is to keep system python isolated and stable for system stability. That can happen if someone installs python from python.org and copies it into place. > but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs. If you are working with SW engineers, you better know what versions you are pulling in, because you are going to be in serious pain using pip and trying to understand the provenance of your packages. Conda is way more powerful here for serious engineers to specify exact versions and reproducible and exact builds.
infraredcabbage 6y ago
This sort of attitude is the reason why the world doesn't move away from awful solutions. It is a testament to the lack of ability to see beyond your own nose. A lot of people who use Python, don't have the luxury of it being their "daily driver for years", so the conflicting documentation, decision paralysis and other problems that come with it end up being a huge time sink. A lot of non-programmers are being forced to use Python for various automation tasks. A lot of the CAD-software that construction engineers use, support Python-plugins. Network admins that have been configuring switches and routers on CLI for decades now have to configure them using Python. Look at "cargo" to see what the world could be like.
- gen220 6y ago
  You're right of course. Still, it's worth keeping in mind that Rust was born 20 years after Python was. Python was being written before Mosaic, Netscape, and Yahoo! were around. I think it can be forgiven for failing to conceive of a perfect package management system in 1990s. There were bigger fish to fry back then, so to speak. Over the decades (!) there have been many, well-documented attempts at coming up with a package management story. pip and virtualenv have been the obvious winners here for years. So, in conclusion, again you're right. But 30 years of history produces a lot of "conflicting documentation". It's only the last 10 years or so, that people have fought over the superiority of one language's package management ecosystem or another.
  - oblio 6y ago
    This comment is rewriting Python history quite a bit. First of all, Python was created around 1989 yet Python 1.0 was released in 1994. Secondly, Python was a pretty obscure language until Python 2.0 (and even long after that...), released in 2000. So realistically, Python had "only" about 15 years of historical baggage :-) Also, cargo can be ignored because it's "new", but there was a lot of prior art in the area of good programming language specific package managers. CPAN (Perl) was launched in 1993. Maven (Java) was launched in 2004. Python just botched its package management story, that's it. Sometimes stuff happens just because it happens, there's no good excuse for how things are. Sad, but true.
deleted 6y ago
[deleted]

philwelch 6y ago

As an individual that probably works just fine. In a team setup, it takes a lot of training and effort for everyone to consistently follow a manual pip/venv workflow, so it becomes valuable to minimize and standardize it.

throwaway894345 6y ago
Especially if you have to deploy to production and you want fast, reproducible builds, or you don't want to run a bunch of tests for things that haven't changed.

olalonde 6y ago

To be blunt, maybe you just don't know what you're missing out on? Of course, Python's package management system works and is merely an annoyance to those of us who are used to more modern package managers. By the way, your comment reminded me a of this classic: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 :)

madelyn 6y ago
I mean, possibly? What's considered the gold standard in package management these days? I use yarn for managing javascript dependencies and do a lot of work with Cargo too. The community seems to love both these tools outside of slow compile and install times.
- throwaway894345 6y ago
  Cargo is my ideal, but really anything that doesn't make me manage virtualenvs or take 30 minutes to resolve dependencies. Note that "managing my own virtualenvs" is tricky because you have to make sure everyone has all of the same versions of the same dependencies in their virtualenv across your entire team (including production). I'm sure there are workflows that allow for this (probably with some tradeoffs), but we haven't figured it out. For a while we used Docker, but performance degraded exponentially as our test base grew (Docker for Mac filesystem problems, probably). Eventually we settled on pantsbuild.org which has a lot of problems, is super buggy, no one can figure out its plugin architecture, etc but as long as you stay on the happy path it generally works okay which puts it in one of the ballparks between any other Python dependency management scheme I've tried and Go/Rust/etc package management.
  - stuhood 6y ago
    Great experience report: thank you! Wanted to point out that the Pants project has been focusing on widening that happy path recently (...by narrowing its focus to Python-only in the short term), and is ramping up to ship a 2.0. This page covers some of the differences between v1 and v2 of the engine, and particularly its impact on Python: https://pants.readme.io/docs/pants-v1-vs-v2 https://pants.readme.io/docs/pants-v1-vs-v2 ... We're using Rust and haven't bootstrapped yet, so we also appreciate Cargo and think that there is a lot to learn there. We'd love feedback (via any of these channels: https://pants.readme.io/docs/community https://pants.readme.io/docs/community) on how to make it even better. Thanks!
    - throwaway894345 6y ago
      That’s great to hear. Is there any page that documents the architecture of pants? I understand build systems of various kinds quite well, but I can’t tease out the design philosophy behind pants, especially how the different target types / plugins end and the “core” begins. I’m going to dig into that 2.0 link though!
d0mine 6y ago
I've used a few (modern and not). Any package management system becomes uglier the more use cases it needs to support.

IshKebab 6y ago

I don't think your experience is atypical but I do think your acceptance of something that is quite awful is fairly atypical. It's also possible that you use Python on Linux, where it is at least tolerable. Try again on Windows.

ssully 6y ago
I develop Python exclusively on Windows (that then is deployed on Linux) and my experience is identical to the original poster. It's not a perfect system, but it's good enough and I have dealt with dependency management systems.

a_cool_username 6y ago

Let me start by saying: I love python, and I love developing in it. It's the "a pleasure to have in class" of languages: phenomenal library support, not too painful to develop in, nice and lightweight so it's easy to throw together test scripts in the shell (contrast that with Java!), easy to specify simple dependencies + install them. (contrast that with C!). That said... if you work on software that is distributed to less-technical users and have any number of dependencies, python package management is a nightmare. Specifying dependencies is just a minefield of bad results. - If you specify a version that's too unbounded, users will often find themselves unable to install previous versions of your software with a simple `pip install foo==version`, because some dependency has revved in some incompatible way, or even worse specified a different dependency version that conflicts with another dependency. pip does a breadth-first search on dependencies and will happily resolve totally incompatible dependencies when a valid satisfying dependency exists.[1] - If you specify a version with strict version bounds to avoid that problem, users will whine about not getting the newest version/conflicting packages that they also want to install. Obviously you just ignore them or explain it, but it's much more of a time sink than anyone wants. - In theory you can use virtualenvs to solve that problem, but explaining how those work to a frustrated Windows user who just spent hours struggling to get Python installed and into their `PATH` is no fun for anyone. Python's made great strides here with their Windows installers, but it's frankly still amateur hour over there. - Binary packages are hell. Wheels were supposed to make Conda obsolete but as a packager, it's no fun at all to have to build binary wheels for every Python version/OS/bitness combination. `manylinux` and the decline of 32-bit OSes has helped here, but it's still super painful. Having a hard time tracking down a Windows machine in your CI env that supports Python 3.9? Too bad, no wheels for them. When a user installs with the wrong version, Python spits out a big ugly error message about compilers because it found the sdist instead of a wheel. It's super easy as a maintainer to just make a mistake and not get a wheel uploaded and cut out some part of your user base from getting a valid update, and screw over everyone downstream. - Heaven help you if you have to link with any C libraries you don't have control over and have shitty stability policies (looking at you, OpenSSL[2]). Users will experience your package breaking because of simple OS updates. Catalina made this about a million times worse on macos. - Python has two setup libraries (`distutils` and `setuptools`) and on a project of any real complexity you'll find yourself importing both of them in your setup.py file. I guess I should be grateful it's just the two of them. - Optional dependencies are very poorly implemented. It still isn't possible to say "users can opt-in to just a specific dependency, but by default get all options". This is such an obvious feature, instead you're supposed to write a post-install hook or something into distutils. - Sometimes it feels like nobody in the python packaging ecosystem has ever written a project using PEP420 namespaces. It's been, what, 8 years now? and we're just starting to get real support. Ridiculous. I could go on about this for days. Nothing makes me feel more like finding a new job in a language with a functioning dependency manager than finding out that someone updated a dependency's dependency's dependency and therefore I have to spend half my day tracking down obscure OS-specific build issues to add version bounds instead of adding actual features or fixing real bugs. I have to put tons of dependencies' dependencies into my package's setup.py, not because I care about the version, but because otherwise pip will just fuck it up every time for some percentage of my users. [1] I am told that this is "in progress", and if you look at pip's codebase the current code is indeed in a folder marked "legacy". [2] I 100% understand the OpenSSL team's opinion on this and as an open source maintainer I even support it to some degree, but man oh man is it a frustrating situation to be in from a user perspective. Similarly, as someone who cares about security, I understand Apple's perspective on the versioned dylib matter, but that doesn't make it suck any less to develop against.

acomjean 6y ago

I think it depends on the use case. If I'm developing my own stuff my peen package management is fine. If trying to run various existing python programs to analyze biology data, I soon run into various problems. Is this a Conda?/ or can I use my Python environment? which version of python? will let me run the thing and what libraries do I need? This breaks in that version? Sometimes I feel that one kinda ok way of doing things, would be better than having 6 ways , one of which will suit my use case perfectly. This problem is not unique to python.

dfsegoat 6y ago
> Is this a Conda?/ or can I use my Python environment? Can you elaborate a bit there? I use conda because I like some of their features over standard virtualenv (being able to specify a python version when i create my venv) - but I've never had a problem running code in env's created by one vs. the other.
- acomjean 6y ago
  Sometimes developers distribute their software via Conda installs, in those cases they sometimes don't provide instructions on running other ways (eg using the pyenv environment which is my default. ). I'm ok with this, but when conda fails as sometimes happens, it can mean some digging to get the install to work. I was thinking of my latest install, which was CRISPRESSO2, which installs via docker or bioconda... I was able to get it going, but it took a bit on some systems.. (Python 2.7 old libraries.. etc..) Docker didn't seem to work. I like virtual env, but sometimes I feel I have to have a new environment for each piece of software I'm running, which feels weird. https://github.com/pinellolab/CRISPResso2 https://github.com/pinellolab/CRISPResso2

franga2000 6y ago

When it comes to shipping Python server-side apps, Pipenv is a godsend. Before discovering it, I had 3 requirements.txt files (common, dev, prod) which I had to edit manually. This often meant forgetting to include something that I just installed and only finding out after a full round of QA. It also meant a separate couple of steps for full-tree dependency freezing which never worked quite properly anyways. Pipenv just....works. Dependencies are saved as I install them, I only have to deal with the top-level ones, but the whole tree is locked.

WD-42 6y ago

The only time I run into problems is when someone else is trying to use Conda. Then it can be hell trying to get their code running in standard pip/venv or vice versa. I'm sure Anacona filled a niche at some point, but we have wheels now, can we all just agree to stop using Conda? What value does it actually bring now that makes it worth screwing up the standard distribution tools?

darkarmani 6y ago
Isn't a conda environment just python installed into an isolated directory where someone can run pip? One can just run pip and pretend it isn't a conda environment.
- WD-42 6y ago
  It's way more than that. Firstly, most Anaconda installations come shipped with libraries like Matplot, numpy, etc. So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py. Then there's the issue of Anaconda using it's own package repos, so even if you do manage to figure out what packages an Anaconda developed piece of software needs, you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs. Lastly, certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder. I get that it's convenient for scientists that just want to write scripts and have them work, but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs.
  - darkarmani 6y ago
    > So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py. How is that any different than using python.org python? You'd still be unaware of what versions to use. > you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs. That's way more of a problem with pip. You have no idea what versions a pip package is pulling in until install and then what binary actually gets installed depends on your compilers. > certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder. That's impossible unless one is actually copying binaries manually overtop of system binaries. You'd have to be root or use sudo to overwrite the system python manually. The whole point of isolation is to keep system python isolated and stable for system stability. That can happen if someone installs python from python.org and copies it into place. > but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs. If you are working with SW engineers, you better know what versions you are pulling in, because you are going to be in serious pain using pip and trying to understand the provenance of your packages. Conda is way more powerful here for serious engineers to specify exact versions and reproducible and exact builds.

infraredcabbage 6y ago

This sort of attitude is the reason why the world doesn't move away from awful solutions. It is a testament to the lack of ability to see beyond your own nose. A lot of people who use Python, don't have the luxury of it being their "daily driver for years", so the conflicting documentation, decision paralysis and other problems that come with it end up being a huge time sink. A lot of non-programmers are being forced to use Python for various automation tasks. A lot of the CAD-software that construction engineers use, support Python-plugins. Network admins that have been configuring switches and routers on CLI for decades now have to configure them using Python. Look at "cargo" to see what the world could be like.

gen220 6y ago
You're right of course. Still, it's worth keeping in mind that Rust was born 20 years after Python was. Python was being written before Mosaic, Netscape, and Yahoo! were around. I think it can be forgiven for failing to conceive of a perfect package management system in 1990s. There were bigger fish to fry back then, so to speak. Over the decades (!) there have been many, well-documented attempts at coming up with a package management story. pip and virtualenv have been the obvious winners here for years. So, in conclusion, again you're right. But 30 years of history produces a lot of "conflicting documentation". It's only the last 10 years or so, that people have fought over the superiority of one language's package management ecosystem or another.
- oblio 6y ago
  This comment is rewriting Python history quite a bit. First of all, Python was created around 1989 yet Python 1.0 was released in 1994. Secondly, Python was a pretty obscure language until Python 2.0 (and even long after that...), released in 2000. So realistically, Python had "only" about 15 years of historical baggage :-) Also, cargo can be ignored because it's "new", but there was a lot of prior art in the area of good programming language specific package managers. CPAN (Perl) was launched in 1993. Maven (Java) was launched in 2004. Python just botched its package management story, that's it. Sometimes stuff happens just because it happens, there's no good excuse for how things are. Sad, but true.

deleted 6y ago

[deleted]