On Fri, May 25, 2012 at 4:23 PM, Erik Bray <span dir="ltr"><<a href="mailto:erik.m.bray@gmail.com" target="_blank">erik.m.bray@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Fri, May 25, 2012 at 2:24 PM, Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:<br>
> This discussion is confusing because we are either talking about a<br>
> general plugin discovery mechanism for Python, or a plugin mechanism<br>
> that packaging itself uses.<br>
><br>
> After the patch, entry_points.txt (which you are encouraged to write<br>
> yourself) is copied by means of a new {dist-info} category using the<br>
> resources = mechanism in packaging. This is a straightforward way to<br>
> copy anything into the .dist-info directory. Apart from copying the<br>
> file, 'packaging' has no role.<br>
><br>
> setup.cfg:<br>
><br>
> [files]<br>
> packages = mypackage<br>
> resources =<br>
> entry_points.txt={dist-info}<br>
><br>
> That's all there is to it.<br>
<br>
</div></div>Neat! I didn't realize there was a {dist-info} resource category.<br>
That, plus the register_finder() approach mentioned in the other<br>
thread could be a way to go for interoperability with packages using<br>
setuptools. It would still require a bit of hackery though... I<br>
suspect there would be resistance to adding support for this directly<br>
in packaging. But a setup_hook could set this up.<br></blockquote><div><br>Ideally, one should just be able to add sections to setup.cfg itself to describe the entry points. Better yet: just include setup.cfg in the dist-info directory, and then the replacement for entry points can look for arbitrary sections in setup.cfg files. (The downside: slower first-use performance, since every setup.cfg would have to be read at least once, but on the upside, all subsequent entry point lookups would be faster.)<br>
<br>Is setup.cfg already in dist-info? I guess if it isn't, you could just add it, using the same mechanism above. Hm.... (goes to look at packaging docs)... Ouch. I'm seeing a bigger problem, which is that without either the ability to do "setup_requires" or to ship an sdist with a hook-altered setup.cfg, it doesn't look like you can actually implement all of setuptools' build functionality with just packaging. (e.g. Setuptools can ship an sdist whose contents and version were determined using revision control info, but which does not then require the revision control tool when installing from the sdist, as the sdist contains a pre-built manifest, and a pre-built setup.cfg with hardcoded version numbers copied from the original revision control info.)<br>
<br>I really hope I'm not going to have to write setuptools2 to work around these limitations. ;-) (Preferably, if I do write a setuptools2, I hope it can all be done using proper setup hooks on top of packaging/distutils2, without monkeypatching anything.)<br>
</div></div><br>