[Distutils] Best practices for accelerator modules?

[Phillip J. Eby]

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:

http://mail.python.org/pipermail/distutils-sig/2007-February/007192.html

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.