[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
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