> So Python's package system is more simple / brainless.
That's sort of my point. site-packages is basically a deep, dark pit that you can toss stuff in without trouble, but there is no obvious way to actually manage things once they're in there.
Basically I think Python really needs something like 'gem', and I feel like I'm the only one, which confuses me. shrug
> Basically I think Python really needs something like 'gem'
Huh? Does RubyGems manage versions?
In Ruby you have the same issues as with Python ... you still have a RUBYPATH and you still need to manually manage versions.
What 'gem' indeed does ... it can upgrade or delete installed gems ... and in Python the available utilities (easy_install and pip) don't.
But that's actually OK IMHO. In Python for pip-installed packages ... you just delete the package's directory or egg file. The conventions for Python's packages really help here.
And RubyGems is the nightmare of sys-admins. If you want a really good (maintainable / replicable) production setup, you need to use the standard package utilities of your OS ... e.g. aptitude and .deb packages for Debian/Ubuntu.
Otherwise you'll encounter conflicts between aptitude and /var/lib/gems all the f*ing time.
So no ... a good production setup is either using stuff like aptitude, which can manage external dependencies and can warn you against version conflicts ... or with a locally deployed site-packages (with stuff like virtualenv or sandbox for Ruby).
Rubygems is just a hack useful for the developer's localhost (the 'gem' utility, not the indexed repository of packages ... that's really useful, but Python has that with Pypi)
That's sort of my point. site-packages is basically a deep, dark pit that you can toss stuff in without trouble, but there is no obvious way to actually manage things once they're in there.
Basically I think Python really needs something like 'gem', and I feel like I'm the only one, which confuses me. shrug