Eggs, VirtualEnv, and Apt - best practices?

Diez B. Roggisch deets at
Thu Sep 25 22:55:21 CEST 2008

> that is a very valid point, but it seemed that Scott has homogeneous
> environment: Debian/Ubuntu so my post was relative to the original request.
> I agree that when you throw Windows/MacOS into the mix things
> become "interesting". But then it's better when your developers develop on
> server/platform they are going to be using, using same stack they going to
> face in production etc. It all depends on requirements and current
> practices in company. 

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 

And other constraints such as Photoshop not being available for Linux 
can complicate things further.

>>   - keeping track of recent developments. In the Python webframework
>> world for example (which the OP seems to be working with), things move
>> fast. Or extremly slow, regarding releases. Take Django - until 2 month
>> ago, there hasn't been a stable release for *years*. Virtually everybody
>> was working with trunk. And given the rather strict packaging policies
>> of debian and consorts, you'd be cut off of recent developments as well
>> as of bugfixes.
> 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.

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.


More information about the Python-list mailing list