[qmtest] [PATCH] Removing ExtensionClass dependency

[Nathaniel Smith]

On Sun, Apr 13, 2003 at 09:27:34PM -0700, Mark Mitchell wrote:
> On Sun, 2003-04-13 at 16:07, Nathaniel Smith wrote:
> > These complement each other.  The overall idea is that after applying
> > my patch, it will become possible to install qm to one of the standard
> > python package directories, instead of /usr/local/lib/qm.  
> 
> I think I know where we're having a disconnect.
> 
> I thought we put all of the QM stuff in site-packages/qm.  In that case,
> stuff that's already under lib/qm (like zope-dtml) can just stay; it
> won't stomp on anything.  I think you're thinking of putting QM stuff at
> the top-level in site-packages.
> 
> Is that right?

Hmm.  *ponder ponder ponder*

Oh.  I see.

I didn't know about the .pth mechanism; every package I've played with
has just stuck its stuff directly in site-packages/, and I hadn't
realized we could have a whole directory to ourself.  (Though I note
that my /usr/lib/python2.2/site.py says that "FOR DEBIAN" the .pth
mechanism is applied to the /usr/local hierarchy as well as /usr.
qmtest wants to install to /usr/local/ by default, so I'm not sure
whether we can trust the .pth trick to work... in fact, Zack informs
me that Redhat 8.0, at least, does _not_ check for .pth's under
/usr/local.)

But if we can use a .pth then something like
  site-packages/qm.pth 
   - contents:
   """qm/qm
      qm/zope-dtml/DocumentTemplate
      qm/zope-dtml/ExtensionClass"""
  site-packages/qm/
   - contents: what we currently have in /usr/lib/qm
should work fine.

> If you're willing to go with my scheme, then we can:
> 
> (1) First move what's in share/qm into lib/qm, because there's no
> site-packages equivalent of share.

Nod.  This is a touch ugly, and might get the Debian people annoyed
about policy and all that... there is some precedent, though; on my
system, 4Suite stores its .mo files under
/usr/lib/python2.2/_xmlplus/dom/.  Should work, though.  It also lets
use find the share path by examining __path__, which is much nicer
than depending on it being set in the environment...

> (2) Turn lib/qm into site-packages/qm.
> 
> After doing (1), we can eliminate some of the setup_path gunk, because
> now all we need is the lib/qm path.  Once we put this in site-packages,
> we can eliminate the rest of it, because now everything is in the
> standard place.

Nod.  I'm still a bit worried about being able to tweak the python
path via .pth, given that it might break on some systems with some
install paths.  And my original proposal still works, so I wonder what
the relative advantages are.  The main things I can think of are my
original plan requires we keep around some explicit knowledge of the
share path somewhere instead of being able to use __path__; on the
other hand, it doesn't require .pth support.  Anything else?

-- Nathaniel

-- 
Sentience can be such a burden.

This email may be read aloud.