[Grok-dev] Re: Martian as an external in the Grok trunk
faassen at startifact.com
Thu Jan 24 17:55:44 EST 2008
Jan-Wijbrand Kolman wrote:
> Even if the solution is not perfect (and in fact, if others have
> suggestions I'd very much like to hear it), but at least we don't need
> an svn:external to a supporting library nor to have a buildout.cfg with
> a develop directive that points to anything but the project itself.
Unfortunately your proposal sounds more complicated to me than just
adding an svn:external to Martian.
Anyway, I'm still not entirely sure what we are trying to accomplish. It
seems like we have various goals:
a) make life easy for those who develop the Grok trunk (and wnat to
develop other things in parallel with it at times)
b) make life easy for those who depend on the Grok trunk
c) make the release process easier in the face of parallely developed
I don't think there's much we can do about c).
I don't see how setting up an index page is going to help you any when
releasing Grok. When releasing Grok you'd *still* need a release of
Martian be available, and having such dev link on pypi sounds *less*
clear to anyone and it sounds more risky a release will happen with the
dependency on dev package.
So concerning the release process, if a dependency like martian is
developed in parallel, you do need to take care of releasing martian or
any other dependencies of development versions that Grok relies on. Of
course martian might stabilize earlier than grok in which a new release
can be done before (the external removed again at that point). That was
the idea when I added it; some changes to martian until it looks stable
enough for a release, *before* a new grok release happens.
I think the current approach with the externals is the easiest to
fulfill a). Note that if I were developing zope.interface and Grok in
parallel, Grok relying on new features or fixes in zope.interface, I'd
do the same thing; install zope.interface as a development package, and
in order to allow the grok trunk to remain buildable, introduce an external.
Concerning b), I'm not entirely sure what is so hard about also adding
martian as a develop egg. You can then put this in a [versions] section
in your buildout.cfg to make sure you get the newest version of martian:
I imagine having some form of directly-from-SVN dev package may help b),
though you'd still be relying on your own versions, or alternatively we
put the dev version in Grok's 'versions.cfg' (dangerous). I'm trying to
understand how doing this makes life better.
Is there a way to make b) easier without affecting procedure a)? Put a
download_url in the setup.py of Martian, and add something like
If I read the setuptools documentation correctly (quite possibly I'm
not), you could then depend on martian = dev to get the SVN checkout.
More information about the Grok-dev