[Distutils] Organizing for buildout questions

Jim Fulton jim at zope.com
Tue Nov 28 11:45:17 CET 2006

David Pratt wrote:
> Hi. I am trying to get my head around using buildout with both private 
> and public repositories. So my questions relate to a way to organize my 
> svn in a better way for eggification and construction of a simple 
> sandbox to keep my svn checkouts together in a consistent and portable 
> way. The goal is to checkout sources, modifying and checking in my 
> changes as I go, and having the buildouts in their own folders reflect 
> the changing code and dependencies.
> My first couple of questions are whether buildout can use a folder as 
> source for a (development) egg - something that will update,

Yes. (I wonder if I understand your question.)

 > secondly
> whether an egg can be created with ssh to a private repository like:
> svn+ssh://myaccount@myrepo.example.com/usr/home/myaccount/svn/path 
> /to/my/project
> I have been using ssh for private code sources.

Yes.  You check out the projects you want to work on and then
configure buildout to create develop eggs from them.  The rule of
thumb is, use develop eggs for checkouts.  It doesn't matter
if the checkouts are public or private.

Note that you can also have private egg repositories using sftp.
See: http://www.python.org/pypi/zc.buildoutsftp

> In a recent buildout I have been studying, I have seen this:
> find-links = http://download.zope.org/distribution/
> I am also looking at a simple sandbox structure that could also make 
> some sense ...
> development --+-- private-src (private checked out sources)
>                |
>                +-- public-src (external checked out sources)
>                |
>                +-- buildout (a container for my active buildouts)
> My source containers would just hold folders of checked out code I am 
> currently working on. I plan on checking out my buildouts from svn to a 
> buildout container so that I could have a few or more different 
> buildouts going at a time (each being an app or just testing some things 
> in their own environment)
> I am curious about folders as sources since sometimes I just want to try 
> some code without a lot of hassle or committing it to a repository right 
> away. I think it would be good to try it in a buildout. With the 
> structure of my development folder I could use a relative link from a 
> source folder as well.

Note that I strongly prefer to keep buildouts self contained.

Typically, for each package I work on, I make the svn project for that
package a buildout.  The buildout.cfg therefore usually has:

   develop = .

I use eggs for everything else needed to work on the package.

If, for some reason, I want to work on another package at the same
time, I'll check that out into the working directory for the first
project(or add an external) and add it to the list of develop eggs.

> On the repository side, I have been looking at zope's repository more 
> critically which is structured like this:
> container-->branch-->src-->namespace-->package

Right, where container == project

> or when more nesting needed:
> container-->branch-->src-->namespace-->second namespace-->package
> setup.py is always at the branch with __init__ for eggs within each 
> namespace package. It seems a good model for eggification since many 
> packages are setup for eggs in a way that is fairly transparent. This of 
> course is a public repository with packages being registered in PyPI.

The main downside of course, is all the nesting, which can get
tedious.  I wish I could think of a way to have namespace packages
without creating all of the annoying subfolders.

I may start omitting the src directory in some projects.  I also
think that it was a mistake to create the zc.recipe namespace packages.
Rather than zc.recipe.foo, I should probably have done zc.foorecipe.
I may switch to this in the future to reduce the nesting.

> For a private repository, I would like to checkout the code as eggs 
> equally as well.

Why not follow the same pattern as for public projects?  I don't
see why a project's structure should depend on whether it is
public or private.


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

More information about the Distutils-SIG mailing list