[Zope3-dev] Re: RFC: Known working sets

[Tres Seaver]

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

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?

Why not just release a meta-egg with hard-wired dependencies, plus the
scripts required to set up and run the application?  If the other
components are as relaxed as possible about their dependencies, then it
shouldn't matter that the meta-egg nails them down:  it isn't going to
be possilbe to re-use the meta-egg anyway (and I for one wouldn't want
to -- I'd be creating a new environment to run it in).

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

Depending on another WS would basically Just Work (TM) if we used egg
dependencies.

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

I guess I don't get the usecase for maintaining "known good"
dependencies outside of setup.py (for the "meta" egg).


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

iD8DBQFG3Jb6+gerLs4ltQ4RAsnCAJ4gVDaVp3Q23zERjzexEVjDgYjf6gCfecSv
sf4f3BZxwVvqxgJ4FASX+3w=
=O0Ea
-----END PGP SIGNATURE-----