Scott Sharkey schrieb:
Hello all,

Our development group at work seems to be heading towards adopting python as one of our standard "systems languages" for internal application development (yeah!). One of the issues that's come up is the problem with apt (deb packages) vs eggs, vs virtual environments.
We're probably gonna end up using Pylons or TurboGears for web-based
apps, and I've recommended virtualenv, but one of the other developers has had some "inconsistencies" when mixing systems with python installed from apt (all our servers are debian or ubuntu based) vs when installed under virtualenv.

I have basically recommended that we only install the python base (core language) from apt, and that everything else should be installed into virtual environments. But I wanted to check to see how other enterprises are handling this issue? Are you building python from scratch, or using specific sets of .deb packages, or some other process.

Any insight into the best way to have a consistent, repeatable, controllable development and production environment would be much appreciated.

This is the exact way we are deploying our software. You can even use the virtualenv --no-site-packages option to completely isolate the VE from the underlying system site-packages.

I would recommend that all you install into the system python is virtualenv, and maybe some uncritical C-modules such as psycopg2.

Currently there is much going on regarding setuptools. A fork, "Distribute" has been announced, and "pyinstall" by Ian Bicking, an easy_install replacement that deals with some of it's ancestors shortcomings.

Then people (shameless plug warning: including me) are working on "eggbasket", a PYPI-clone that allows to have a local repository of eggs so that you don't fall prey to old versions not longer available on PYPI.

Eggbasket will feature "easterbunny", a tool to publish a virtualenv as whole to the eggbasket and also keep track of the precise version set uploaded. Through a specific url on eggbasket you can then limit the contents of eggbasket to that exact version set - which helps dealing with subtle (or not so subtle) version conflicts.

I personally can say that I'm really thrilled by the prospects of all these developments. And as much bad rap as setuptools had here and elsewhere, sometimes rightfully so - it certainly does a lot of stuff right, and pushing the whole stack of tools to manage software dependencies in Python to the next level is of great value.

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to