[Grok-dev] Re: zc.sourcefactory

[Tres Seaver]

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

Philipp von Weitershausen wrote:
> On 4 Sep 2007, at 01:26 , Tres Seaver wrote:
>> Philipp von Weitershausen wrote:
>>> Sebastian Ware wrote:
>>>> Shouldn't dependencies be put in setup.py like this (?):
>>>>
>>>>       install_requires=['setuptools',
>>>>                         'grok',
>>>>                         'zc.catalog==1.1.1',
>>>>                         'hurry.query',
>>>>                         'hurry.workflow',
>>>>                         # Add extra requirements here
>>>>                         ],
>>> Yes, dependencies should be put in there, but not specific versions.
>> I think there are cases for pinning specific versions:  removing
>> "degrees of freedom" here can be a sanity saver.  As I noted in  
>> another
>> thread, I think that we end up solving the "known good working set"
>> problem by creating an egg whose only job is to pin down the  
>> versions of
>> all its dependencies.
> 
> If zc.buildout (or setuptools, not sure which one's to blame here)  
> actually had a decent algorithm for resolving dependencies, then I'd  
> say you're right about reducing degrees of freedom. Sadly, it isn't  
> the case.
> 
> Consider Jan Ulrich's example in this very thread:
> 
> * Jan Ulrich's app -- let's call it 'zoo' for now -- depends on  
> 'grok'. Grok depends on ZODB3==3.8.0b2. So it actually pins down the  
> ZODB, fulfilling the job of the meta/framework egg.
> 
> * Now Jan Ulrich wants to make use of zc.sourcefactory. 'zoo' now  
> depends on 'grok' and 'zc.sourcefactory'.
> 
> * 'zc.sourcefactory' OTOH depends on ZODB3 as well. Because it's a  
> *library* (not a meta/framework/application egg) it doesn't and  
> shouldn't pin down a version. zc.buildout isn't smart enough to  
> understand that grok's requirement is more specific than this one.

The bug is in setuptools;  it downloades and *installs* eggs before
doing the full workingset computation.  The problem is that the
dependencie metadata is not available until after the egg becomes
importable (e.g., installed at least to the extent that 'pkg_resources'
can find it).

If PyPI exposed the dependency information as metadata, which setuptools
then checked *before* downloading the eggs, this issue would be solvable.

> It  
> will actually try and download the latest ZODB3 for zc.sourcefactory  
> and then bail out with an error because it conflicts with the version  
> pinned down for grok.
> 
> 
> That, and the fact that it's currently impossible to override any  
> version dependencies that are made with the '==' operator, I consider  
> such pinnings in setup.py both ineffective (because they don't remove  
> degrees of freedom for grok) and hazardous (because they constrain  
> *me* instead).

I'm afraid they are goint to be *necessary*, whether we like them or
not:  nobody can expect to run against a "wild West" collection of
distributions without building a packaging culture rivaling Debian's
(even then, 'unstable' *does* break people's systems).


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

iD8DBQFG3KB9+gerLs4ltQ4RAkrbAKCLSK/k8D8ujljwlZhgh6R3ECqtLQCgx0uX
3ewDVofarNIXiO69/C/d1sc=
=NfDS
-----END PGP SIGNATURE-----