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