-----BEGIN PGP SIGNED MESSAGE-----
Jim Fulton wrote:
> Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Nathan R. Yergler wrote:
>>> During the Zope3 sprint following PyCon, Paul and I, with Jim's
>>> guidance, began work on exploring how Zope can utilize eggs and be
>>> packaged using eggs. Since we're still experimenting with how eggs
>>> will be used, I wrote a script, zpkgegg, which reads the zpkg
>>> configuration information for a package and generates a "standard"
>>> setup.py from which an egg and vanilla sdist can be generated.
>>> You can find the script in subversion in the projectsupport project.
>>> For a brief overview of how the script is used, see README.txt (in
>>> http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs
>>> generated by zpkgegg do not attempt to distinguish between "runtime",
>>> "testing" or "development" dependencies, so almost all packages will
>>> want zope.testing. README.txt contains a brief example of how to
>>> point easy_install at the appropriate folders so that easy_install can
>>> resolve the dependencies.
>>> Note that at this point we're still experimenting with how we'll use
>>> eggs, so suggestions, feedback and comments are welcome.
>> I've been playing around a lot, trying to get at least the eggs together
>> to make ZPT usable outside of Zope (one of the original sprint goals).
>> I have a couple of observations:
>> 1. Putting 'setup.cfg' under version control sucks, because the
>> 'develop' framework scribbles on it. I think we should do two things:
>> - Move any "special" settings to a 'setup.cfg.in', and modify the
>> workspace stuff to read that first when creating setup.cfg.
>> - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk).
> Agreed. IMO, we should either not scrible on setuop.cfg or not check it in.
> I vote for not scribbling on it.
I'd rather not check it in, myself. Even if the 'develop.py' helper
doesn't scribble, it is a natural place for the developer to scribble.
Generating it when needed, and ignoring it for version control, seems
healthier to me. Perhaps we should use a different strategy for
"released" packages than "trunk" ones?
>> 2. Getting the development dependencies installed was harder than
>> it seemed. Some packages (perhaps with help from a stanza in
>> 'setup.cfg') could do that when running 'develop.py'; others
>> needed me to run 'setup.py develop'. Maybe we should just kick
>> off 'setup.py develop' at the end of the 'develop.py' dance?
> I suspect these are just lingering bugs.
> One thing I noticed, when I tried a few days ago was that zope.testing
> had a bogus dependency that made it's installation fail.
>> 4. We need to begin creatinng "released" versions of the eggs (maybe
>> numbering them according to the Z3 release they point into), and
>> reorganizing the download page a bit (maybe "development" builds
>> need to go on one page, and "release" builds on another).
> Why do you say this? I agree that we need this eventually, but it
> feels a bit early to me.
I think that getting the eggs usable outside of Zope is a goal, and one
which makes getting the packages "released" more urgent than simply
changing Zope to use them (which won't happen until November at the
earliest). Many of the packages are actually very stable, and could
easily be released now, assuming some elbow grease is applied.
> Also, I expect and hope that many packages
> will have release cycles independent of Zope.
That will require that they get maintainers who actively manage them.
One sign of such a package is that it has its own CHANGES.txt file, and
that its bugfix / feature entries end up there, rather than in Zope's
changelog. For the time being, I'll be content with packages which
merely point into the release tag area of Zope.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list