3 ms·
> 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 witho
by tvon 17y ago
> 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
- bad_user 17y ago> 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)