extensions project and packaging/distutils
qwcode
there's a blog post from tarek on 3/21/11 where he says:
>>Q: What’s the future of “entry points” ?
>>A: packaging will allow adding extra custom metadata. So the plan is to create a third-party project that >>provides a similar feature than entry points.
is that 3rd party project this?: https://bitbucket.org/tarek/extensions
is this considered a live project?
also, there's there's a post to this list on 5/12/11 where tarek says
>>1/ defining entry points
>> - setuptools: entry_points option in setup.py
>> - d2: a custom metadata in setup.cfg
>>2/ installing entry points:
>> - setuptools: entry_points.txt in egg-info
>> - d2: CUSTOM in dist-info
>>3/ browsing entry points
>> - setuptools: pkg_resources APIs
>> - d2: pkgutil APIs
>>So it seems to me that there's nothing to ship more
just want to make sure this last comment doesn't intend to negate the
need for something like the extensions project?
thanks
Marcus
Alex Grönholm
> I apologize if this has been clearly laid out somewhere already.
>
> there's a blog post from tarek on 3/21/11 where he says:
>>> A: packaging will allow adding extra custom metadata. So the plan is to create a third-party project that>>provides a similar feature than entry points.
> is that 3rd party project this?: https://bitbucket.org/tarek/extensions
> is this considered a live project?
>
> also, there's there's a post to this list on 5/12/11 where tarek says
>>> 1/ defining entry points
>>> - setuptools: entry_points option in setup.py
>>> - d2: a custom metadata in setup.cfg
>>> 2/ installing entry points:
>>> - setuptools: entry_points.txt in egg-info
>>> - d2: CUSTOM in dist-info
>>> 3/ browsing entry points
>>> - setuptools: pkg_resources APIs
>>> - d2: pkgutil APIs
>>> So it seems to me that there's nothing to ship more
> just want to make sure this last comment doesn't intend to negate the
> need for something like the extensions project?
>
> thanks
> Marcus
distributions. If distutils2 enables that, then people could make any
number of extensions-like libs that scan the distribution metadata for
compatible extensions. Of course it would be preferable to have a
setuptools-like de facto standard for that, but that's not as important
as getting it working in the first place. But I don't work on packaging
so I can't tell you what's been decided and what hasn't.
Éric Araujo
Le 08/02/2012 01:14, qwcode a écrit :
> I apologize if this has been clearly laid out somewhere already.
No problem, this is the right place to inquire about anything related to
distutils2 development.
> there's a blog post from tarek on 3/21/11 where he says:
>>> Q: What’s the future of “entry points” ?
>>> A: packaging will allow adding extra custom metadata. So the plan is
> to create a third-party project that >>provides a similar feature than
> entry points.
>
> is that 3rd party project this?: https://bitbucket.org/tarek/extensions
It is.
> is this considered a live project?
It is not. :) extensions was (IIRC) the first idea on how to handle
entry points, that is, use a standalone plugin system that’s independent
of any packaging tool.
> also, there's there's a post to this list on 5/12/11 where tarek says
>>> 1/ defining entry points
>>> - setuptools: entry_points option in setup.py
>>> - d2: a custom metadata in setup.cfg
>>> 2/ installing entry points:
>>> - setuptools: entry_points.txt in egg-info
>>> - d2: CUSTOM in dist-info
>>> 3/ browsing entry points
>>> - setuptools: pkg_resources APIs
>>> - d2: pkgutil APIs
>>> So it seems to me that there's nothing to ship more
> just want to make sure this last comment doesn't intend to negate the
> need for something like the extensions project?
I actually think it does. Custom metadata in setup.cfg is defined in
http://docs.python.org/dev/packaging/setupcfg#extensibility
In short, they are keys that start with X-. Now, the second part of the
idea (not yet implemented) is to collect these custom fields and write
them in a file named CUSTOM in the dist-info directory (I think I
remember a much older message from Tarek with more detail about that,
but I can’t find it).
Recently, there was this bit of discussion launched by Alexis on
python-dev, to which I still need to reply:
http://mail.python.org/pipermail/python-dev/2012-January/115825.html
If you have any other questions about entry points/plugins, feel free to
ask.
Regards
qwcode
> In short, they are keys that start with X-...
> them in a file named CUSTOM in the dist-info directory
access?
tarek's email mentions "pkgutil APIs"?
but it looks the effort has ocurred in "packaging.database", is that
right?
you'd use a combination of "packaging.database.get_distributions" and
"Distribution.metadata"?
Marcus
Éric Araujo
> ok, that covers defining, and persistence, but I'm not clear on api
> access?
> tarek's email mentions "pkgutil APIs"?
> but it looks the effort has ocurred in "packaging.database", is that
> right?
Yes.
> you'd use a combination of "packaging.database.get_distributions" and
> "Distribution.metadata"?
Yes.
I’ll try to make time in the next weeks to re-read old and new
discussion about this and write a patch to implement the writing of the
CUSTOM file.
Regards
Erik Bray
So, just to make sure I understand this correctly: In order to
implement an entry-point-like plugin system this way, one would define
a metadata extension named similarly to an entry point, where its
value could be the path to that entry point? For example, something
like
entry_points={
"setuptools.filefinders": ["svn_cvs" =
"setuptools.command.sdist:_default_revctr"]
}
might be implemented as
X-Setuptools-Filefinders =
svn_cvs = setuptools.command.sdist._default_revctrl
?
Then use the API to read all X-Setuptools-Filefinders from the CUSTOM
files? Seems like a reasonable solution. My only concern is different
applications implementing subtly different extension systems through
this mechanism. Maybe that flexibility could be considered a good
thing. But it would also not be a bad idea to document a
'recommended' pattern for using this mechanism. For example,
encourage the use of packaging.util.resolve_name to parse object
import paths.
Don't get me wrong--I don't think packaging *needs* a complicated
extension system built into it. I think something built around custom
metadata seems like a good approach that doesn't require adding much
to the existing design. But for better or for worse, the setuptools
entry_point system did provide a decent common interface for plugins,
and lots of packages depend on it. So it should be made easy as
possible to transition to any new mechanism.
Erik
Alex Grönholm
standard distribution will NOT be extensible (ie. one can't add plugins
for different types of repositories, say depot.io for example)? That
would be a crying shame.
Erik Bray
> Also, am I correct in understanding that the installer shipped with the
> standard distribution will NOT be extensible (ie. one can't add plugins for
> different types of repositories, say depot.io for example)? That would be a
> crying shame.
AFAIK packaging doesn't have built-in support to do anything in
particular with VCSs. Though there's nothing stopping anyone from
writing a setup hook, command hook, or custom command that does. But
that depends entirely on what you want to *do* with some repository,
be it creating file manifests, generating version strings, or what
have you.
For example, I've written a setup-hook that checks for the SVN
revision if the code is in an SVN working directory and appends in to
the Version metadata in the appropriate format (x.y.z.dev123).
The expectation is that some standard plugins for different VCSs will
emerge, as it doesn't make sense to try to support every possible VCS
in the core (especially ones that are still evolving rapidly). But
for that to work out packaging (and PEP 345) still need a
Setup-Requires-Dist or something of the like.
Erik
Alex Grönholm
plugins) would be very nice indeed.
>
> Erik