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 -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org