On Tue, May 5, 2009 at 1:47 AM, David Lyon <david.lyon@preisshare.net> wrote:
Hi Tarek,
On Tue, 5 May 2009 01:37:34 +0200, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Furtermore, if we provide the ability to fill egg-info with third party packages registered through a plugin system, it make sense to prepare it at packaging time to avoid having to install this third party package on the target system.
I'm trying to understand why there is a need for a "new" plug-in system.
Isn't the site-packages directory already a very simple and effective plug-in system?
Does not the .PTH file provision... with it's "import .." prefix capability, allow any code to be run through the .PTH?
This is not a registery that indexes code under specific markers : you are not able for instance to ask "give me all classes that are filling the .egg-info dir so I can use them on this 'foo' package" for this you need a system that let you register your classes under the 'write-into-egg-info' group, with an unique name for each, no matter where the class is located in your package. That is what entry points are providing : the ability to mark a code locate anywhere in your installation and to load it when needed in your execution context.
I'm not suggesting don't change anything. I'm just wondering about the implications on my own project and trying to support both old and new installations.
A lot of windows packages just come with their own windows installer... how would your proposed system work with these?
I don't think it affects any of these topics. Tarek -- Tarek Ziadé | http://ziade.org