3 ms·

> ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of i

by snuxoll 10y ago

> ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).

kstrauser 10y ago
> I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.
- snuxoll 10y ago
  virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
  - takeda 10y ago
    You have mixed up history line. Eggs are older than virtualenv, from the times of easy_install. Now there are wheels that are nicely integrated with pip. Also virtualenv became integrated into python (it's called pyvenv now).
- anamoulous 10y ago
  Another option here is to pin your Python version to whatever Anaconda is. It's very easy to install and use Anaconda in production.

by snuxoll 10y ago

kstrauser 10y ago

> I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.

snuxoll 10y ago
virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
- takeda 10y ago
  You have mixed up history line. Eggs are older than virtualenv, from the times of easy_install. Now there are wheels that are nicely integrated with pip. Also virtualenv became integrated into python (it's called pyvenv now).
anamoulous 10y ago
Another option here is to pin your Python version to whatever Anaconda is. It's very easy to install and use Anaconda in production.