[Distutils] Best practices for accelerator modules?
Mike C. Fletcher
mcfletch at vrplumber.com
Sun Feb 11 00:40:42 CET 2007
In a number of my OpenGLContext projects I have "accelerator" modules,
small, optional C extensions which are optional, and thus likely
"extra_requires" candidates. I gather the best practice for these
things is to create a separate .egg with some name like
"PyVRML97-frustum-accelerators-numpy" with some weird internal package
name that won't create a new conflict in the global namespace? Is that
a correct understanding?
(The situation is actually somewhat more complex in that some of the
accelerators are actually numpy/Numeric version dependent (that is, they
can only run against the version of numpy/Numeric against which they
were built). I'm planning on handling that by having the accelerator
module examine the Numeric/numpy version and add that explicit version
to its dependencies so that only that version will satisfy the dependency.)
i.e. I'm thinking of an egg named PyVRML97-frustum-accelerators-numpy
with a package/module named 'PyVRML97-frustum-accelerators-numpy' so
that the pollution of the top-level namespace will be minimised with the
package's entry points being used to resolve the references without
regard to their "unimportability".
And that rather convoluted plan makes me think "is this really
recommended practice"?
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
More information about the Distutils-SIG
mailing list