Eggs，VirtualEnv和Apt - 最佳实践？ [英] Eggs, VirtualEnv, and Apt - best practices?
问题描述
大家好，
我们的工作开发小组似乎正在采用
python作为我们标准的系统语言之一。内部
应用程序开发（是的！）。其中一个问题是问题与apt（deb软件包）相比，鸡蛋还是虚拟环境。
我们可能会结束使用Pylons或TurboGears用于基于网络的
应用程序，我推荐了virtualenv，但其他开发者之一
有一些不一致。当安装python系统混合
来自apt（我们所有的服务器都是debian或ubuntu）vs安装时
在virtualenv下。
我基本上建议我们只从apt安装python base（core
语言），并且其他所有内容都应安装到
虚拟环境中。但是我想查看其他企业如何处理这个问题？你是从头开始构建python，还是使用
特定的.deb软件包或其他一些过程。
任何洞察最好的方法来获得一个一致，可重复，
可控制的开发和生产环境将非常值得赞赏。
关于构建/推出工具的建议（如zc.buildout，Paver等）也会赞赏
。
谢谢!!!
- Scott
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.
Suggestions on build/rollout tools (like zc.buildout, Paver, etc) would
also be appreciated.
Thanks!!!
-Scott
推荐答案
Scott Sharkey写道：
Scott Sharkey wrote:
任何有关最佳方法的见解一致，可重复，
可控的开发和生产环境将非常值得赞赏。
Any insight into the best way to have a consistent, repeatable,
controllable development and production environment would be much
appreciated.
你刚刚描述了操作系统包构建;）
我不能代表所有人，但支持多个平台（PHP，Perl，
Python，Java）我们发现保持一致的唯一方法是使用OS
本机打包工具（在你的情况下为apt和.deb）如果你遗失了
的东西 - 滚动你自己的包裹。过了一段时间，你会积累大量的
模板，以便在你需要的时候选择另一个库不可用
以你喜欢的包格式上游
。请记住，一些python工具
可能依赖于非python包，因此确保所有
在环境中保持一致的唯一方法是使用统一包管理。 />
很抱歉，不是具体的指示，因为我们是redhat商店和debs不是我们的日常业务。
you have just described OS package building ;)
I can''t speak for everybody, but supporting multiple platforms (PHP, Perl,
Python, Java) we found that the only way to stay consistent is to use OS
native packaging tools (in your case apt and .deb ) and if you''re missing
something - roll your own package. After a while you accumulate plenty of
templates to chose from when you need yet-another-library not available
upstream in your preferred package format. Remember that some python tools
might depend on non-python packages, so the only way to make sure all that
is consistent across environment - use unified package management.
Sorry, not specific pointers though as we''re redhat shop and debs are not
our everyday business.
Dmitry S. Makovey写道：
Dmitry S. Makovey wrote:
你刚刚描述了操作系统包构建;）
我可以'不是代表所有人，而是支持多个平台（PHP，Perl，
Python，Java）我们发现保持一致的唯一方法是使用OS
原生包装工具（在你的情况下为apt和.deb），如果你缺少
的东西 - 滚动你自己的包。过了一段时间，你会积累大量的
模板，以便在你需要的时候选择另一个库不可用
以你喜欢的包格式上游
。请记住，一些python工具
可能依赖于非python包，因此确保所有
在环境中保持一致的唯一方法是使用统一包管理。
you have just described OS package building ;)
I can''t speak for everybody, but supporting multiple platforms (PHP, Perl,
Python, Java) we found that the only way to stay consistent is to use OS
native packaging tools (in your case apt and .deb ) and if you''re missing
something - roll your own package. After a while you accumulate plenty of
templates to chose from when you need yet-another-library not available
upstream in your preferred package format. Remember that some python tools
might depend on non-python packages, so the only way to make sure all that
is consistent across environment - use unified package management.
你在很多组织中说话，至少。
来自供应商的存储库的
rpm / debs
颠覆（或等效）-locally build rpm / debs
+组织'最喜欢的部署工具
------- --------------------------
已部署的应用程序
< / F>
you''re speaking for lots of organizations, at least.
rpm/debs from supplier''s repository
subversion (or equivalent) -locally built rpm/debs
+ organization''s favourite deployment tools
---------------------------------
deployed application
</F>
Scott Sharkey schrieb：
Scott Sharkey schrieb:
Hello all，
我们的工作开发小组似乎正在采用
python作为我们的标准系统语言之一。内部
应用程序开发（是的！）。其中一个问题是问题与apt（deb软件包）相比，鸡蛋还是虚拟环境。
我们可能会结束使用Pylons或TurboGears用于基于网络的
应用程序，我推荐了virtualenv，但其他开发者之一
有一些不一致。混合使用python系统的时候来自apt（我们所有的服务器都是基于debian或ubuntu的）和安装时的
在virtualenv下安装
。
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.
我基本上建议我们只从apt安装python base（core
语言），其他一切应安装到
虚拟环境中。但是我想查看其他企业如何处理这个问题？你是从头开始构建python，还是使用
特定的.deb软件包或其他一些过程。
任何洞察最好的方法来获得一个一致，可重复，
可控制的开发和生产环境将非常值得赞赏。
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.
这是我们部署软件的确切方式。您甚至可以使用
virtualenv --no-site-packages选项将VE
与底层系统站点包完全隔离。
我建议您安装到系统python中的所有内容都是
virtualenv，也许还有一些非关键的C模块，如psycopg2。
目前关于setuptools的事情很多。叉子，
" Distribute"已经宣布，并且pyinstall作者：Ian Bicking，一个
easy_install替代品，用于处理其中的一些祖先
缺点。
然后是人（无耻的插件警告：包括我）正在开发
eggbasket，这是一个PYPI克隆，允许拥有一个本地鸡蛋库
，这样你就不会在PYPI上不再提供老版本的牺牲品。
Eggbasket将以easterbunny为特色，这是一个将virtualenv发布为
整个工具的工具。 eggbasket并跟踪精确版本集
已上传。通过eggbasket上的特定URL，您可以将eggbasket的
内容限制为该确切的版本集 - 这有助于处理带有微妙（或不那么微妙）版本冲突的
。
我个人可以说，我对所有这些发展的前景感到非常激动。和setuptools一样糟糕的饶舌和其他地方的b $ b，有时也是理所当然的 - 它肯定做了很多东西
正确，推动整套工具来管理软件
Python中的依赖关系具有很大的价值。
Diez
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
这篇关于Eggs，VirtualEnv和Apt - 最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
