[Zope-dev] Re: SVN: zope.file/trunk/ Make a good package out of this package.

[Tres Seaver]

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

Christian Theune wrote:
> Hi,
> 
> Am Freitag, den 02.11.2007, 10:23 -0400 schrieb Stephan Richter:
>> On Friday 02 November 2007, Benji York wrote:
>>> Stephan Richter wrote:
>>>> On Friday 02 November 2007, Benji York wrote:
>>>>> Why the test extra?
>>>> to get it working. :-) There were several packages required by
>>>> ftesting.zcml.
>>> We generally put those in install_requires and eschew extras.
>> zope.file was the *only* package of the 150+ I worked on that did not have 
>> extras. If this changes, I want a canconical community decision with someone 
>> writing a script fixing it everywhere for the next releases.
> 
> Hmm. I've been doing that dance using extras too.
> 
> I see that there is a special 'tests_require' in setuptools anyway.  We
> could give up on extras using tests_require if the testrunner recipe (or
> buildout) knew how to handle those.
> 
> I (and other gocept guys) unscrewed the dependencies for almost all
> zope.* packages (at least those that come from the old big tree) using
> this approach. We really wanted to get the normal dependencies right
> there, and moving the test dependencies out of the way was a large part
> of that.
> 
> I'm happy using extras to do that. I'm not 100% sure on the complete
> reasoning against extras but my understanding is that this specific use
> case works. Can someone explain whether this use case has a problem too?
>  
>> I know why extras are bad, Jim explained it to me. I would still argue that we 
>> need them (for tests only, of course!!!!). For example, the zope.file tests 
>> require zope.app.zcmlfiles, which effectively pulls in 70 packages, including 
>> the entire ZMI, Rotterdam, and old form framework. But what if I do not want 
>> to install ZMI, Rotterdam and the old form stuff and just use the API of 
>> zope.file?
>>
>> I think that extras for tests are a necessary evil until we have unscrewed the 
>> dependencies of the functional test setups.
> 
> Depends on what 'unscrew' means. Functional test setups might want to
> demonstrate more in-depth, "real-life" scenarios where they have to
> introduce more dependencies than the actual package itself needs, so two
> sets of dependencies are needed anyway, or not?

Maybe the functional tests could declare their dependencies using teh
following idiom (rather than listing them in setup.py):

 import pkg_resources
 from setuptools.command.easy_install import main
 FTEST_REQUIREMENTS = ['foobar=1.2.3', 'bazbam>=3.2']

 try:
     pkg_resources.require(FTEST_REQUIREMENTS)
 except pkg_resources.DistributionNotFound:
     main(argv=FTEST_REQUIREMENTS)
     pkg_resources.require(FTEST_REQUIREMENTS)


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

iD8DBQFHK1gq+gerLs4ltQ4RAmp7AKC+0CqxsNDIBKHC4bxIOqNXtJ0p8gCfUdrU
yhHxOnicWEDsgziA/ISVgU8=
=s3OM
-----END PGP SIGNATURE-----