Plugin support for d2/packaging
Alex Grönholm
Integrated support (like svn support in setuptools) for any VCS is not the way to go of course. Instead, distribution authors could specify dependencies on such packaging plugins and also include URLs that require such plugins.
For example:
[metadata]
requires-dist: packaging-git
requires-dist: git+http://github.com/seb-m/pyinotify.git@43f47fed3a28b7cd62cfcf1bcfa948d7499a0407
Now, packaging does not know how to handle requirements starting with git+http:// so it first installs everything it can. Then it goes for round 2, armed with the git plugin, which handles cloning from the repository. The same mechanism could be used for package indexes other than PyPI.
This requires 1) a packaging plugin API and 2) support for entry points or similar in the stdlib.
If all this is implemented, there would be little reason for most people to install something like setuptools/distribute or pip.
Éric Araujo
I agree that plugins would be a valuable addition. It looks like your
proposal is more about auto-discovery than plugins themselves; the thing
you’re asking for (extended format for requires-dist) can already be
done by a hook.
As you said on IRC, for an example like requires-dist, there are many
ways to deal with the bootstrapping issue (a hook is required to parse
requires-dist, but the hook is part of a dist that must be in
requires-dist too).
- Sum up the discussion we’ve had months ago about setup dependencies
and come up with at patch to add setup-requires-dist to PEP 345.
- Parse as many lines as possible so that dists providing hooks are
found, then parse the failing lines again; example setup.cfg:
[metadata]
requires-dist = distutils2-git
git+http://blah
[global]
setup-hooks = distutils2_git.parse_requires_dist
The bad thing is that setup hooks should run first, before any dep is
installed; not sure running them twice would be good. Looks like we
need to provide automatic extension via something similar to entry
points, so that d2 automatically gets extended parsing rules for
requires-dist *without* having to specify something as setup hook. I’m
not sure how I like changing behavior without explicit configuration.
- Add a custom field processed by your hook:
[metadata]
requires-dist = distutils2-git
x-requires-dist-vcs = git+http://blah
# need to define a hook to clone the repo
# need something else to create the dist-info dir in the clone
I think I’ll look deeper into entry points and the extensions project.
Cheers
Toshio Kuratomi
>
>
> I think I’ll look deeper into entry points and the extensions project.
>
people expressed displeasure with some of the implementation details of
entry points (I very seldom use them so I'm afraid I've forgotten the exact
arguments). It would be good to get that feedback and make sure a d2
implementaiton didn't suffer from the same problems.
-Toshio
Alex Grönholm
Erik Bray
> - Add a custom field processed by your hook:
>
> [metadata]
> requires-dist = distutils2-git
> x-requires-dist-vcs = git+http://blah
>
> # need to define a hook to clone the repo
> # need something else to create the dist-info dir in the clone
>
>
> I think I’ll look deeper into entry points and the extensions project.
+1 I think. The majority of use cases I think are handled fine by
setup-hooks, and perhaps the addition of support for
setup-requires-dist. Other than that I don't see a reason for
packaging to grow a complicated entry-points-like infrastructure. I
thought that was something we were trying to get away from.
Wouldn't it make sense that setup-hooks are run *after* any
setup-requires-dist packages have been imported? That would solve
most of the issues here.
I also like the idea of using a custom field for requirements from a
VCS. That would prevent confusion by other setup-hooks that might
parse requires-dist expecting its contents to be formatted according
to to PEP385.
Erik