[Grok-dev] Re: Martian as an external in the Grok trunk

[Martijn Faassen]

Jan-Wijbrand Kolman wrote:
[snip]
> 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 
dependencies

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:

[versions]
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 
#egg=martian-dev?

If I read the setuptools documentation correctly (quite possibly I'm 
not), you could then depend on martian = dev to get the SVN checkout.

Regards,

Martijn