[Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)

[Brian Sutherland]

On Tue, Jan 03, 2006 at 10:51:04AM -0500, Jim Fulton wrote:
> Brian Sutherland wrote:
> > On Tue, Jan 03, 2006 at 07:13:16AM -0500, Jim Fulton wrote:
> > Because I only realized it was causing a headache for me yesterday.
> 
> I greatly appreciate your working on Debian packaging.  I encourage
> you to take time-based releases into account when doing this.  You should
> try to create Debian based on each of our beta releases, so you don't find out
> late that there is a problem.

Yeah, I know:(

>  >>I am willing to consider a 3.2.1 release for this *after* the final.
>  >
>  >
>  > That would also be fine.
> 
> OK, if you want to proceed with this, then we'll do that.

Ok, I committed my patches to the trunk.

> >>Why do you think you need to do this?
> > 
> > 
> > It is related to the debian packaging of zope 3. It is common practice
> > with these packages to remove modules that can be provided by other
> > debian packages. So far this has been the case only with pytz and docutils.
> 
> I'm guessing that this is an issue because you install
> Zope's into site-packages and you don't want a Zope installed
> package to clobber a package that is separately packaged. Is that right?

Yes, also so that if someone wants to use mechanize, they don't have to
install zope3...

> The normal way to install Zope is in it's own directory.

In this case it becomes a lot more difficult for other programs to use
parts of zope (zope.interface or ZConfig comes to mind).

For example, my schooltool packages can just do "import zope", and it is
there. No additions to sys.path necessary.

> In this case,
> a package supplied with Zope only affects Zope.  In which case, I don't
> see the need to rip it out.  In fact, I would prefer that Zope use the
> versions of packages that came with it, since these are the versions
> it has been tested with. OTOH, if you create a distribution that omits
> packages that are provided separately, you are taking on responsibility for
> assuring that the installed Zope works properly.  I can understand why you
> would want to do this.

Hopefully running the tests without the removed packages will be enough.

I also try only to take these steps with code that is definitively from
a different project (mechanize, pytz, docutils) and is useful in it's
own right.

Actually it is pretty easy to set up a debian chroot which upgrades
itself and tests its Zope 3 installation every week or so. But I am
missing both the time and hardware.

> > The relevant code in the debian rules file is (yes, I know it is nasty,
> > but there doesn't seem to be a "right way"):
> > 
> >     zbase    = Zope-3.2.0b2
> > 
> >     <snip>
> > 
> >     unpack: unpack-stamp
> >     unpack-stamp:
> >             tar xfz $(zbase).tgz
> >             mv $(zbase) z
> >             # Remove docutils and pytz modules packaged in separate packages
> >             rm -rf z/Dependencies/docutils*
> >             rm -rf z/Dependencies/pytz*
> > 
> > I also need to do the same with mechanize and it's dependencies. Since
> > the latest version of mechanize depends on pullparser 0.0.7, I also need
> > to remove pullparser. This is more difficult with the way pullparser
> > is tied into zope today.
> 
> Pullparser is currently distributed within the zope.testbrowser package.
> It can't interfere with anything else. I suppose you just want to eliminate
> the duplication.

No, it's worse than that. I am trying to use mechanize 0.0.11a which
depends and tests for pullparser 0.0.7. Since zope includes an older
pullparser and then mungs sys.modules, it causes the mechanize in
site-packages to fail.

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
              And she's EVIL!!"