3 ms·

Sorry, pet peeve, but... virtualenv is a hack to work around the fact that python packaging is a joke. That said, it seems to be useful.

by tvon 17y ago

bad_user 17y ago
I view it as a tradeoff ... the ability to chdir to the package's directory and look directly at the source-code is priceless to me. The alternative would be a GAC like .NET does, but then you need packages that are compiled in a single file with metadata attached. And you also need to attach to your app a configuration file that says which versions it uses. And in Python the package's name can be relative to the directories loaded in sys.path, a very useful trait, and you also kind of lose that. So Python's package system is more simple / brainless. And you can get by just fine with stuff like virtualenv.
- 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)
deleted 17y ago
[deleted]

Sorry, pet peeve, but... virtualenv is a hack to work around the fact that python packaging is a joke. That said, it seems to be useful.

by tvon 17y ago

Sorry, pet peeve, but... virtualenv is a hack to work around the fact that python packaging is a joke. That said, it seems to be useful.

bad_user 17y ago

I view it as a tradeoff ... the ability to chdir to the package's directory and look directly at the source-code is priceless to me. The alternative would be a GAC like .NET does, but then you need packages that are compiled in a single file with metadata attached. And you also need to attach to your app a configuration file that says which versions it uses. And in Python the package's name can be relative to the directories loaded in sys.path, a very useful trait, and you also kind of lose that. So Python's package system is more simple / brainless. And you can get by just fine with stuff like virtualenv.

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)

deleted 17y ago

[deleted]