2 ms·

For dealing with packages such as python-psycopg2 and python-mysql, your best bet is to use --system-site-packages. This allows the virtualenv to depend on pac

by scott_w 14y ago

For dealing with packages such as python-psycopg2 and python-mysql, your best bet is to use --system-site-packages. This allows the virtualenv to depend on packages provided by your distro instead of trying to compile its own. Wherever possible, I try to do this with Python packages that require a C compiler to make deployment a little easier and reduce dependencies. Personally, I'm not a fan of Fabric and I much prefer configuration management (Salt, Chef, Puppet) because of the added flexibility you get. About the most I use Fabric for is logging into the Salt Master and kicking off a deployment process.

antihero 14y ago
Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm. Never ever ever mix/depend upon system packages in your virtualenv. Ever.
- scott_w 14y ago
  You're always depending on system packages somewhere. Compiling isn't the only reason - sometimes it's necessary just to make the damn thing work. Some examples: * PIL - Using Pip's version on Ubuntu, you have to hack your directory structure and re-compile the whole thing or PIL doesn't compile in support for your image libraries. * psycopg2 - This is hit and miss (OS X comes to mind), but depending on the system version guarantees that it has been tested to work with the specific version of Postgres on your system. * Crypto libraries - Broken packages have ended up on Pip and just cause a bloody headache. The system package is, again, tested and works. Compiling a DEB/RPM would be a good idea, but it's not a well supported system at all. If there were a simple pip compile --type=deb or something, we would be all over it.
  - antihero 14y ago
    PIL - Don't use PIL, use Pillow. Psycopg2 - Well, it's just a client library - surely you will be making sure your client matches your server's version (whether that's local or a clust or whatever)? Sure your system will likely need Postgres headers installed, but why is that an issue? Actually, let me just check that. e: Yeah, you need libpq-dev installed, but I fail to see the point here? You need to make sure you have python-dev and a correct version of Python installed, too. PyCrypto - Hmm, not had a problem with this hugely. What I was suggesting doesn't involve a deb of individual packages, but a deb of the entire app/virtualenv.

by scott_w 14y ago

antihero 14y ago

Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm. Never ever ever mix/depend upon system packages in your virtualenv. Ever.

scott_w 14y ago
You're always depending on system packages somewhere. Compiling isn't the only reason - sometimes it's necessary just to make the damn thing work. Some examples: * PIL - Using Pip's version on Ubuntu, you have to hack your directory structure and re-compile the whole thing or PIL doesn't compile in support for your image libraries. * psycopg2 - This is hit and miss (OS X comes to mind), but depending on the system version guarantees that it has been tested to work with the specific version of Postgres on your system. * Crypto libraries - Broken packages have ended up on Pip and just cause a bloody headache. The system package is, again, tested and works. Compiling a DEB/RPM would be a good idea, but it's not a well supported system at all. If there were a simple pip compile --type=deb or something, we would be all over it.
- antihero 14y ago
  PIL - Don't use PIL, use Pillow. Psycopg2 - Well, it's just a client library - surely you will be making sure your client matches your server's version (whether that's local or a clust or whatever)? Sure your system will likely need Postgres headers installed, but why is that an issue? Actually, let me just check that. e: Yeah, you need libpq-dev installed, but I fail to see the point here? You need to make sure you have python-dev and a correct version of Python installed, too. PyCrypto - Hmm, not had a problem with this hugely. What I was suggesting doesn't involve a deb of individual packages, but a deb of the entire app/virtualenv.