[Zope3-dev] Re: Zope Eggs

[Nathan R. Yergler]

> Agreed. IMO, we should either not scrible on setuop.cfg or not check it in.
> I vote for not scribbling on it.

So right now we scribble the development dependencies as well as path
(lib, script, etc) information into setup.cfg.  The develop.py script
reads the dependency information and attempts to install them into the
specified lib directories.  So it seems to make sense to put things
like egg parameters, etc (settings independent of user workspace
location) into setup.cfg.in, and then have develop.py populate a
setup.cfg at runtime.  I think we really do want a setup.cfg that
isn't under version control -- storing the path information there
makes the easy_install commands somewhat less verbose as you don't
have to specify the script and lib locations each time you run.

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

The one thing I can think of right now is that develop.py looks for
it's dependency information in setup.cfg (as opposed to parameters to
setup() for setup.py commands).  So there is a potential duplication
of information there that may make sense to get rid of.  We looked at
implementing develop.py as a distutils target (setup.py workspace,
say), but ended up ditching it because our test implementation
required setup.py to do something like :

try:
   from foo import setup
except ImportError:
  from distutils.core import setup

(or something like that).  Looking at that now, I suppose it's no
worse than what we have to do now to support easyinstall.  Would that
be a better approach?  Jim, have I forgotten another reason we dropped
that approach?  I have a near complete prototype of that approach
lying around from the sprint.

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

Hmm... I didn't see any dependency information listed for
zope.testing.  Was that an egg you built or one downloaded from
download.zope.org?

>
> ...
>
> > 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.  Also, I expect and hope that many packages
> will have release cycles independent of Zope.
>
> Jim
>
> --
> Jim Fulton           mailto:jim at zope.com       Python Powered!
> CTO                  (540) 361-1714            http://www.python.org
> Zope Corporation     http://www.zope.com       http://www.zope.org
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/nathanyergler%40gmail.com
>
>