On 7/25/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> Florian Lindner wrote:
> > Hello,
> > I use a Zope3 svn checkout for developement. What is the best way to
> > make this working with the zc packages? I don't want to easy_install
> > the entire Zope checkout but I also want my code to work with
> > easy_install'ed versions of these packages. (don't want to change
> > import statements and so on...)  My favorite way would be to just
> > do a svn checkout of the zc packages too but it seems to me that it
> > won't work this way (or am I missing something?)

$ mkdir zc
$ touch __init__.py
$ cd zc
$ svn co ..../zc.resourcelibrary/trunk/src/zc/resourcelibrary

And then additional checkouts. Basically:

- Create an empty 'zc' package with an empty ``__init__.py``
- Go into that directory
- When making checkouts from the zc packages in the subversion repository, go
  into the 'src' instead of getting the root which has the 'setup.py'. So if
  it's zc.resourcelibrary, typically you will want to check out
  `trunk/src/zc/resourcelibrary`.

> Of course you can get a checkout of any package you wish from
> svn.zope.org, including the zc.* packages. However, they'll likely have
> dependencies which you will have to resolve as well. Some might also
> define entry points which means they really want to be installed as eggs.
>
> Why do you use checkouts? Do you actually change the packages while
> you're developing with them?

FWIW, we use checkouts at Bottlerocket because that's how we use our
own packages. And there are many packages which don't have eggs, or
don't have good releases as eggs. For example, there's
zc.resourcelibrary - release 0.6 had a serious bug, and I haven't
checked to see if there's been a fixed release made since then.

For packages like that, we don't do blind checkouts, but we stick with
a certain revision number so that we don't get surprised if the code
starts using Zope 3.4 features while we're still using 3.3.

We handle dependencies semi-manually, semi-automatically. I ended up
writing our own build-ish system, inspired by Ruby's Rake, primarily
to automate all of the SVN and CVS checkouts, their associated tags,
and so on.

> Have you looked at zc.buildout? Checkout the tutorial [1]. Also, pretty
> much any zope.* or zc.* package's sandbox is set up using buildout these
> days, providing you with lots of examples.

Last time I checked, which I admit has been a while, buildout didn't
provide any examples of how to transition into buildout style
development.

NONE of our internal code - at least, none of our Zope-focused code is
in egg style format. I've been checking out or exporting or
unzipping/untarring into either $INSTANCE_HOME/Products or
$INSTANCE_HOME/lib/python for nearly a decade. I don't know how to
write a new product or library in this style. I don't know how to
safely and securely deploy it so that it's only accessible by our
internal, deployment, and home and office machines (cvs over ssh has
worked fine for us, again, for six-plus years).

Even more overwhelming - I don't know how to transition our existing
code - internal frameworks and customer projects - into an egg-ish
format. And I really don't know where we'll find the time.

I still don't know how Eggs work. setuptools documentation, while
comprehensive, is about as clear as mud in many places. I don't
understand development eggs. And it looks like only subversion is
supported for those anyways, am I right?

``zc.buildout`` is something that I'd like us (my company) to start
using. But at present, it's overwhelming. It was overwhelming enough
that it was easier to write our own automation system that fit in with
the way we've worked for so many years than to try to figure out
buildout, eggs, all of the various half documented recipes, etc. I
feel like I need a training course or consultancy to move to buildout,
which requires time and money that we just don't have.

-- 
Jeff Shell
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to