[reportlab-users] More 2.2 questions - package rearrangement

Andy Robinson andy at reportlab.com
Mon Sep 1 15:41:44 EDT 2008


2008/9/1 Dirk Holtwick <dirk.holtwick at gmail.com>:

> More on setuptools here:

> <http://peak.telecommunity.com/DevCenter/setuptools>


Aha. We're talking at cross purposes. Since lunchtime Robin and I have been
talking about making a distutils-based package, and you're assuming
a setuptools-based one.

(I spent half of today figuring out what had messed up my site-packages
after "easy-installing" something which installed separate versions of
reportlab, PIL, and a load of zope packages it didn't even need, without
asking my permission first. -1 for an initial experience! But I concede that
setuptools sounds good...)


> So you may find the parent directory from runAll.py like this:

>

> import os.path

> parent = os.path.join(os.path.dirname(__file__), os.pardir)


I agree with this. The docs, demos and tests can assume "import reportlab"
works, because the developer will have either installed it already or will
have put 'src' on the path. But if they want to find each other (e.g. a test
to verify that the docs will build, or find a logo or something), they
should just backtrack
up the directory tree rather than looking 'relative to the package'.

FYI no one will EVER execute "import rl_addons". That is a physical directory
containing the C extension source code, which (when built and installled)
will result in two extensions "_renderPM" and "_rl_accel" being
available on the path.
It would not be there in a build Windows distro, for example.
We have a separate directory in version control because people didn't
like having
a ton of C source mixed in with the Python code.

Sounds like we are getting there on the layout.

- Andy


More information about the reportlab-users mailing list