Okay, commence telling me I'm an idiot for thinking PHP has some ideas worth looking at.
Package management is not rocket science, but it's very political in terms of deciding who should be heard and who should be let down by The One True Blessed Way Of Packaging.
I like python too but the packaging ecosystem is nowhere near where it should be.
It's replaced virtual_env and friends for me, and with some more experimentation it might also replace apt for my own packages deployed to other machines. It's written in Python and for Python, but it's much less python-centric than you might expect, and it is nothing short of excellent.
edit: so what that it beats rvm? bundler + ruby-install does everything that you need and works very well.
That's my biggest gripe with Python packaging. Fundamentally, virtualenv is a hack for the fact that the Python ecosystem fundamentally doesn't embrace that one computer can have different projects with different dependencies. Compared to npm (for example), it's much much worse.
As one of the maintainers of virtualenv, it's my goal to move that project so that it will use the venv isolation mechanism when it is available, and have virtualenv just provide a level of UX overtop of it as well as shims for versions of Python that don't have the venv module.
Not even slightly, virtualenv is the answer to exactly that problem.
Doing that isn't really much different than a virutal environment though. The only real difference is that in a virtual environment you essentially have "named" (by file system path) sets of dependencies that are automatically "activated" when you start up the Python interpreter. In the setuptools/bundler style you have in memory sets of dependencies that are activated by calling a particular API, often done automatically via a binstub.
Exactly. That's my point: you shouldn't need an additional tool to solve this problem.
If anything, the problem with Python is that it does have built in packaging tools - which inevitably became outdated, and just as inevitably remained in the standard library, aka the place where modules go to die. Everyone agreed that the standard tools were terrible, but because they were standard they hung on much longer than they should have.
setuptools isn't tied to the stdlib, though it had many problems and still does. A large portion of what was holding back improvements was that there was nobody really pushing through all the political nonsense surrounding the tooling, and there was nobody to say Yes/No when a consensus couldn't be reached. For normal featured there was the PEP process, but the PEP process didn't work for a long time for packaging because Guido admits he really doesn't care much about packaging at all. Now that we have BDFL-Delegates in the form of Nick Coghlan and Richard Jones and we have people willing to push through changes even when it takes a lot of pain to argue the points we're finally seeing the engine of progress start to grind to start.
However, you know what else needs improvement? PyPi. PyPi is downright embarrassing compared to rubygems, npm, etc... and not only needs a facelift but a whole redesign. This is the reason that I absolutely love to use python but dread using a python library that I haven't heard of 1st hand. Treading outside the standard library is an exercise in sifting through garbage.
Want to see which package for a "x" is most popular? No problem for any dynamic language besides python. However, search for "http" on pypi and you'll get a list of packages by weight which does not take into account popularity or download count or views, just the score of a textual match.
Why is that important? Well when you search for "http" you get these as pypi's top choices (no help at all):
Pypi isn't even serving up the latest version of the python packages it has some of the time (see: SCons).
All of this leads me to think the Pythonistas have given up on PyPi which does more to hurt the community than you can imagine: It leaves a bad taste in the mouths of those looking for quality libraries and software when they reach for Python as their tool of choice.
The whole Python 3 situation? :)
edit: relevant bug and argument: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...
- wheels are more common, and popular libraries (scipy, cryptography) have packages built at least for windows. On linux it's not a big deal since we have package managers.
- setuptools is now the only stuff we need again, since all has been merged in it.
It's still not very clear, but it's much better than before.