Buildbot
Patrick Gerken
I like to have buildbot test packages on that I change stuff.
Usually I create a buildout.cfg per package and test only that single package.
That way I can find missing dependencies that would go unnoticed when
other packages installed these dependencies.
I also found, that testrunners never find tests if package paths begin
in the base path of the projects.
so ./p4a/image/tests/*.py is never run in tests, but
./src/p4a.image/tests/*.py would be found.
Thus I would need to move the source code into a src directory, and I would
modify setup.py to understand that.
afaik the history of the files gets lost during that move.
If you use p4a.image as a checkout, nothing needs to be changed.
Buildout uses the setup.py information to find the package, so
the path would be updated correctly.
Since the history issue is a big issue, I ask for permission first.
The packages in questions are
p4a.image
p4a.ploneimage
For those interested, I am working on getting plonetruegallery to work
without galleries so that it can more easily be used with p4.ploneimage
I can also answer questions at the plone conference, I might be running
around with a light green syslab shirt. It might not be me, in that case
you either ask that person where I am or look for a guy half naked and
unconscious.
Best regards,
Patrick
Ross Patterson
> I like to have buildbot test packages on that I change stuff.
> Usually I create a buildout.cfg per package and test only that single package.
> That way I can find missing dependencies that would go unnoticed when
> other packages installed these dependencies.
Thanks a lot for contributing to P4A. Having buildbot coverage on the
P4A packages would be great!
> I also found, that testrunners never find tests if package paths begin
> in the base path of the projects.
> so ./p4a/image/tests/*.py is never run in tests, but
> ./src/p4a.image/tests/*.py would be found.
> Thus I would need to move the source code into a src directory, and I would
> modify setup.py to understand that.
Actually, the p4a buildout finds tests just fine with the current
layout. The problem you report is only applicable if the egg *is* the
buildout. Since P4A is a single project with a lot of packages I'm not
convinced that making each package a buildout is valuable or otherwise
worth the maintenance burden. For example, when we change to Plone 4
with a fully eggified Zope2, then how many changes would we have to make
if each P4A egg is it's own buildout?
Just the same, there's no need to make each package it's own buildout
just to have a buildbot for each package. As such, I'd prefer you make
these buildbot buildouts *outside* the packages themselves such that if
they fall out of repair the eggs themselves won't appear to be broken
(as would be implied with a buildout.cfg in each egg root). Maybe you
can make a buildbot directory inside the p4a directory in the
collective. Then you could make your buildbots in there.
> afaik the history of the files gets lost during that move.
> If you use p4a.image as a checkout, nothing needs to be changed.
> Buildout uses the setup.py information to find the package, so
> the path would be updated correctly.
Any modern version control system (such as SVN) has a way to preserve
history across a move like this. For svn this is "svn mv" (see "svn
help mv"). Just the same, considering the above and any lack of
familiarity with moving stuff in a VCS, I feel pretty strongly that you
should not do this move.
Even when history is moved, it still introduces VCS headaches in some
cases. For new projects or isolated projects, I always use a "src"
directory but I just don't see enough benefit to do it here.
> Since the history issue is a big issue, I ask for permission first.
> The packages in questions are
> p4a.image
> p4a.ploneimage
For the reasons above, I'm -1 for this change as the most recent major
contributor to these eggs.
> For those interested, I am working on getting plonetruegallery to work
> without galleries so that it can more easily be used with p4.ploneimage
I hope my -1 above doesn't discourage you from doing this. This sounds
like a great contribution and I'm very excited to have others
contributing to these eggs. :)
> I can also answer questions at the plone conference, I might be running
> around with a light green syslab shirt. It might not be me, in that case
> you either ask that person where I am or look for a guy half naked and
> unconscious.
Unfortunately, I'm not there this year. But give me a holler on IRC
(nick: zenwryly) if you have any questions!
Thanks again,
Ross
Patrick Gerken
>> I also found, that testrunners never find tests if package paths begin
>> in the base path of the projects.
>> so ./p4a/image/tests/*.py is never run in tests, but
>> ./src/p4a.image/tests/*.py would be found.
>> Thus I would need to move the source code into a src directory, and I would
>> modify setup.py to understand that.
>
> Actually, the p4a buildout finds tests just fine with the current
> layout. The problem you report is only applicable if the egg *is* the
> buildout. Since P4A is a single project with a lot of packages I'm not
> convinced that making each package a buildout is valuable or otherwise
> worth the maintenance burden. For example, when we change to Plone 4
> with a fully eggified Zope2, then how many changes would we have to make
> if each P4A egg is it's own buildout?
>
> Just the same, there's no need to make each package it's own buildout
> just to have a buildbot for each package. As such, I'd prefer you make
> these buildbot buildouts *outside* the packages themselves such that if
> they fall out of repair the eggs themselves won't appear to be broken
> (as would be implied with a buildout.cfg in each egg root). Maybe you
> can make a buildbot directory inside the p4a directory in the
> collective. Then you could make your buildbots in there.
I did not consider that possibility yet. It sounds good to me.
I would create some base.cfgs for different plone versions and then a
small cfg for each package.
I am very strongly in favor of one buildout per package, because
missing dependencies is one of those
problems that are never really considered and for that buildbot to hit
you on your head is really great.
I am a bit clogged, so it might take a week or two untils its done,
but as soon as its there I'll post a link.
Best regards,
Patrick