Eggs, VirtualEnv, and Apt - best practices?

Dmitry S. Makovey dmitry at athabascau.ca
Thu Sep 25 17:30:19 EDT 2008


Diez B. Roggisch wrote:
> Well, you certainly want a desktop-orientied Linux for users, so you
> chose ubuntu - but then on the server you go with a more stable debian
> system. Even though the both have the same technical and even package
> management-base, they are still incompatible wrt to package versions for
> python.
> 
> And other constraints such as Photoshop not being available for Linux
> can complicate things further.

actually I had in mind X11 sessions forwarded from server to desktop - all
development tools and libraries are on server, and all unrelated packages
(like Photoshop etc.) are on desktop.

>> that definitely becomes tricky however not impossible to track. You do
>> need a common snapshot for all developers to use anyway - so why not just
>> package it up?
> 
> I do, but based on Python eggs. They are platform independent (at
> ultimo, you can use the source distribution, albeit that sux for windows
> most of the time), and as I explained in my other post - things are
> moving in the right direction.


/I'll play devil's advocate here even though I see your point/

how do you deal with non-pythonic dependencies then? surely you don't
package ImageMagic into an egg ;)

> Don't get me wrong - I love .deb-based systems. But if using them for my
> development means that I have to essentially create a full zoo of
> various packages *nobody else* uses - I rather stick with what's working
> for me.

Looks like if you package and make those available you'll have quite a few
people using them. I've seen people looking for pre-packaged python libs
just to stick to OS package management tools. :)

Eggs and debs are not silver-bullet for *any* scenario, so you'd have to
weight what can you get out of either one against what are you going to
sacrifice. In my case I know all our systems (servers) run same OS, however
developers don't. So I provide them with environment on devel/testing
servers that they can use as a primary development environment or develop
on their own boxes (which means they are on their own hunting
dependencies/packages/etc.) but testing before moving forward they still
have to test it on "certified" server. And I don't suggest that everybody
should run *this* type of environment - it just works better in our case.





More information about the Python-list mailing list