[Distutils] Best practices for accelerator modules?

Phillip J. Eby pje at telecommunity.com
Sun Feb 11 01:39:05 CET 2007

At 06:40 PM 2/10/2007 -0500, Mike C. Fletcher wrote:
>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"?

Mostly, there isn't a good practice for this.  See this thread:


for some recent discussion on one possible approach that doesn't actually 
exist yet.  :(

Your concept of using entry points is rather interesting.  I hadn't thought 
about that as a way to ensure matching versions, but it could work.  Still, 
as you say, it's a convoluted plan.

More information about the Distutils-SIG mailing list