[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