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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
