[qmtest] [PATCH] Removing ExtensionClass dependency

[Mark Mitchell]

On Sun, 2003-04-13 at 22:43, Nathaniel Smith wrote:
> 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. 

I didn't know about ".pth" either!

I did know that you can create a directory under site-packages for your
app; for example, in my site-packages, there's an "OpenSSL" directory,
and I can do:

  import OpenSSL

to get at the stuff in there.

The .pth thing is a cool additional trick, though!

> > 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...

Agreed.  The Debian people are just going to have to lump it until
Python comes up with some other mechanism; we have to have a place to
put these files.

> 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?

I think the main advantages of my proposal is that it's easier to get
there from here (in that we don't need to move as much stuff around) and
that we really keep from stepping on other stuff (because all of our
stuff is down one level in site-packages).  The other thing is what you
say: we've now got a pretty easy path out of the setup_path stuff.

QMTest installs in /usr/local just because it always has; if on
GNU/Linux systems it makes sense to install in site-packages we can
easily change it to do that.  If site-packages is
/usr/lib/python*/site-packages, we'll want to put the "qmtest" script in
/usr/bin, rather than /usr/local/bin, of course.  (Independently of
whether or not it stops being a Bourne shell script at some point.)

-- Mark