[Distutils] setuptools 0.6c7 and zc.buildout: find-links egg fragment issue

[Jim Fulton]

On Feb 7, 2008, at 4:14 PM, Tarek Ziadé wrote:

>
>
> Jim Fulton wrote:
>>
>> FWIW, I find this feature to be baroque. I have very little interest
>> in supporting it in buildout. (I wouldn't go out of my way to break  
>> it
>> either.) I'd prefer to explore other ways to deal with the underlying
>> use case in the context of buildout.  I've tried to ignore this issue
>> broadly, but I'm willing to work on an alternate solution because  
>> just
>> seeing the discussion go by is too painful to keep ignoring.
>>
>
> Ok. The use case is : we are working on a bunch of private packages
> that do not have a public distribution.

Have you considered a private repository?

> So we start a buildout like this:
>
>  [buildout]
>
>  develop =
>      ../../packages/my.package
>      ../../packages/my.package2
>
>  eggs =
>     my.package
>     my.package2
>
> Then we create for each package a tag on the svn. And we want to
> distribute our buildout. so we change the buildout this way:

Is your intention to distribute it for production deployment? Or for  
development?

>  [buildout]
>
>  find-links =
>      http://private/packages/my.package/tags/0.1#egg=my.package
>      http://private/packages/my.package2/tags/0.1#egg=my.package2
>
>  extensions = lovely.buildouthttp
>
>  download-cache = downloads
>
>  eggs =
>     my.package
>     my.package2
>
>
> ..to build a buildout that will have those eggs built within the  
> folder.
> Then we add "install-from-cache" and "offline" to provide a  
> installable
> tarball.

Have you looked at zc.sourcerelease?

> Ok, we could release some eggs in some private url to have the proper
> find-links, but the #egg is quite convenient to avoid this extra step.

Just to avoid making a distro?  You're already making an tag.

Why not just use externals?

> So if we can find a way to automate this..

I'm still not clear on what "this" is.  Let me see, you want to be  
able to distribute software that includes develop eggs from svn. Is  
that right?

> 2/ the develop problem
>
> Another point that would be great to consider: setting up the develop
> section can be painful when you share a project among many developers,
> because they need to svn checkout many packages and make sure they
> have the same folder structure.

Unless you use externals.

> So could you consider this feature here :
> http://pypi.python.org/pypi/gp.svndevelop/0.1 ?
> We created this to be able to automate the set of develop on  
> developers
> boxes.
> I think buildout misses this.

Why not use externals?

> 3/ the boostrap.py problem
>
> If we want to have a full offline mode (not using your rpm system)

You mean without zc.sourcerelease?

> with a
> buildout directory,
> we need boostrap.py to avoid trying to get setuptools with an  
> openurl call.
>
> So we have created a special boostrap.py file that first looks in  
> the eggs
> folder,
> to be sure to have a 100% offline mode
>
> https://ingeniweb.svn.sourceforge.net/svnroot/ingeniweb/IngeniSkel/trunk/ingeniskel/templates/iw_plone_project/buildout/bootstrap.py
>
> Could you consider such a feature as well ?

Sure.  I'm unclear on why you don't want to use zc.sourcerelease?

> We work a *lot* with zc.buildout here, and those three points are  
> the three
> things that are missing,
> in the way we use it. I can spare some time to work on some branches.


Cool.

> Oups I forgot one point : being able to tell that a given part in the
> buildout will be run
> only under a given platform win32.


Right, so for other folks benefit, the idea is to be able to say  
something like:

[foo platform=win32]

and have the options defined there provide foo options only on win32.

I definitely plan to do this.

Jim

--
Jim Fulton
Zope Corporation