Re: Re: RFC: Known working sets

On Sep 3, 2007, at 4:13 PM, Philipp von Weitershausen wrote:

> Wichert Akkerman wrote:
>>> The only problem is that distributing grok-0.11.cfg is a bit  
>>> tedious. How about if buildout could get it from the web?
>> How about making it available from an egg, through a hook in egg-info
>> perhaps?
>
> This is a very good point. So good in fact that I thought of it  
> myself :) I was already writing the email when your message came in.
>
>
> Martijn and I discussed the known working set problem over IRC this  
> afternoon. He brought up a few good points which suggest that the  
> version data could be associated with the egg:
>
> The approach that I described in my original posting (and which  
> actually works *today*, as I found out!) has some disadvantages.  
> For instance, the discoverability and release mechanism of the  
> known working set configuration file differs a lot from our normal  
> packages. Releasing a package is a well-known routine by now. How  
> and where would we release the working set configuration file? SVN?
>
> Another problem are dependencies and how we'd like to depend on  
> other working sets. Let's say we made a 'Zope' working set that  
> contained the stable versions of the zope.* packages. It would make  
> sense for grok to depend on this information. And packages using  
> grok should depend on that. It'll be complicated to maintain such a  
> chain in separate text files, especially across version updates. It  
> only seems natural to use the egg dependency mechanism for this.
>
> So, a possible solution is to associate the known working version  
> info with an egg. More to the point, an egg could -- in addition to  
> simply listing the names of its dependencies -- also specify which  
> versions of those eggs it works best with. Wichert and I suggest  
> that this could be put in a file in the EGG-INFO directory.
>
> The only problem is that we usually don't version control egg-info  
> directories. That means the information needs to be contained or at  
> least referenced in setup.py and then written upon "setup.py  
> egg_info". Here's what setup.py *could* look like::
>
>   known_working_versions = {
>     'ZODB3': '3.8.0',
>     'zope.component': 3.4.0,
>     ...
>   }
>
>   setup(
>       name='grok',
>       version='0.11',
>       ...
>       install_requires=known_working_versions.keys(),
>       known_working_versions=known_working_versions
>       )
>
> When EGG-INFO is written, a custom writer will then take this  
> information and generate 'known_working_versions.txt' or whatever  
> in EGG-INFO. The only problem is that this custom writer needs to  
> be installed when setup.py is called to create egg, in other words  
> to generate the right kind of eggs you'd need to have something  
> installed first. Not sure if this is better than maintaining .egg- 
> info directories in SVN...

How would the "known_working_versions" be used?  You haven't  
specified that.  Presumably this would be something that is  
overridable. How would this be overridden?

I'm very much against making setuptools *more* complicated than it  
already is.

Perhaps buildout (and setuptools) should grow a mechanism for being  
able to override/resolve version conflicts.

Jim

--
Jim Fulton			mailto:[email protected]		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org