[Zope-dev] Re: buildout "tests_require" analogue

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> On Nov 15, 2007, at 9:35 AM, Tres Seaver wrote:
> ...
>> Chris is not advocating switching away from zc.buildout for the
>> *development* of the packages;  he is arguing that we can't force  
>> people
>> who *use* the packages to stop using the facilities supplied  
>> setuptools.
> 
> Agreed,
> 
>> If we want people outside the rather small group of core Zope  
>> developers
>> to *use* our software, we are going to need to accomodate their
>> expectations about how Python pacakges work.  At a miniumum, any  
>> package
>> which we release to the Cheeseshop should be testable and installable
>> using the "standard" tool used by nearly everyone:  setuptools.
>>
>> That means we need to work harder at a coule of things:
>>
>>  - Making sure the install-time dependencies in setup.py are accurate,
>>    minimal, and themselves installable.
> 
> Yup
> 
>>  - Making sure that the tests can psss for somebody who is not a
>>    core Zope developer, (and therefore who doesn't know about
>>    zc.buildout, or want to).  E.g.:
>>
>>     $ /path/to/python setup.py develop
>>     $ /path/to/python setup.py test
> 
> Grrrrr. I find "setup.py test" to be really annoying as it requires  
> meta data that is available only to that command.

Not after running 'egg_info', or any other setuptools-aware command;
the tests_require dependencies then become introspectable.  E.g.:

 $ svn co $ZSVN/zope.tal/trunk zope.tal-trunk
 $ cd zope.tal-trunk
 $ /path/to/setuptools-aware/python setup.py egg_info
 $ cat src/zope.tal-egg-info/requires.txt
 setuptools
 zope.i18nmessageid
 zope.interface

 [test]
 zope.testing

>>    If there are dependencies which are needed to run the tests but
>>    not merely to install the package, there should be a way to
>>    spell that.
> 
> Agreed. I'll note that there is a school of thought that I proposed  
> but am somewhat ambivalent about that anything required by tests  
> should also be required by install. This is in accordance with "fly  
> what you test, test what you fly."  To the degree that we do this,  
> then there is no need for tests_require.

There are a bunch of packages out there which contain ZCML, and try to
test the loadability of it.  Those tests end up creating a huge furball
of dependencies which are artificial:  the package itself doesn't need
to process ZCML, and any application which wants to conume the ZCML
provided by the package is going to have those dependencies satisfied
anyway.

>> In setuptools, that is what 'tests_require' is
>>    for;  buildout doesn't (yet) have such a spelling (I think).
> 
> Ideally, buildout (really the testrunner recipe) should be able to  
> honor tests_require, but setuptools doesn't make this information  
> available to any other packages. :( (big frowny)  Also, I believe  
> that more is required to get "setup.py test" to work.  I'm unsure  
> what the details are.

See above.  If buildout can trigger creation of the egg-info directory,
all should be well.  In fact, that directory will already be present in
any source distribution built with setuptools.

> When we do this, we tend to use a test extra.  I suggest that when we  
> use a test extra, we also put the value in tests_require.  I will  
> find this so distasteful that it will help me stick to the strategy  
> of just putting these dependencies in install_requires. :)
> 
>> In order to succeed here, we are going to have to quit releasing
>> packages without more careful thought, testing, etc.
> 
> +1
> 
> This should not be interpreted as criticism of the heroic and well- 
> meaning efforts to date.  Despite that inevitable mistakes that were  
> made, I'm very appreciative of the efforts a few individual people  
> made to make the transition to eggs possible.  I also apologize for  
> not providing more oversight.

Agreed completely (on the heroic part).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHPGtF+gerLs4ltQ4RAiflAKCjtH9ZutX/rL3v4w3qC6antxWUMQCfWgmU
AFNKLCpInKK9xNB3U2Aliws=
=ooWa
-----END PGP SIGNATURE-----