[Grok-dev] Re: Defining 3rd-party eggs within a grok buildout?
Philipp von Weitershausen
philipp at weitershausen.de
Thu Jun 26 02:54:36 EDT 2008
Toni Mueller wrote:
>> Are they an inherent dependency of your application? In other words,
>> does your application import sqlalchemy, zope.sqlalchemy, etc.?
> I sort of solved it by copying the setup from rdbexample, which
> includes a private copy of SQLAlchemy, collective.lead, and megrok.rdb.
>> you should add it to install_requires of your application's setup.py.
>> Next time you run bin/buildout, it will pull these in.
> Mentioning them appropriately in buildout.cfg would be my
> preferred choice, as I also don't see how I could specify package
> versions within setup.py.
You can, but that's typically not the way we do it. The rule simply is
that if your code literally depends on other code, you must list those
dependencies as install_requires in setup.py. buildout is just one way
of deploying your code and other mechanisms should also be aware of
install_requires in setup.py should be as open regarding version numbers
as possible, but should lock down where needed. If your code absolutely
needs one specific version, you can say
Though that's very rarely the case. A more common case is that you need
at least a particular version because older versions didn't contain a
certain feature that you need. So you'd write
Pinning the version number for deploying is then done in buildout.cfg.
But this has nothing to do with declaring dependencies. This just has to
do with getting a repeatable sandbox with the same versions of packages
that you tested your app with. But, this deployment may change of course
and then you wouldn't want to have to change the software (namely
setup.py), just buildout.cfg.
To summarize: dependency info goes into setup.py, version info of
dependencies goes into buildout.cfg.
More information about the Grok-dev