[Grok-dev] Re: Defining 3rd-party eggs within a grok buildout?

[Philipp von Weitershausen]

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 
dependencies.

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

   intsall_requires=['foo==1.3']

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

   install_requires=['foo>=1.3']

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.