Jeremy Katz wrote:
On Mon, 2008-06-16 at 19:20 -0400, Toshio Kuratomi wrote:
Jeremy Katz wrote:
On Mon, 2008-06-16 at 16:39 -0400, Toshio Kuratomi wrote:
Jeremy Katz wrote:
On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote:
I've added Python Virtual Provides to the list of draft guidelines.
https://fedoraproject.org/wiki/PackagingDrafts/Python
[snip]
The motivation for this is that David Malcolm (dmalcolm) wrote a proof
of concept script to show how easy it would be to extract egg dependency
information as part of the rpm build process.
To help maintain the sanity of everyone building packages, can't we just
auto-generate these? I know there's the old patch floating around
somewhere for python deps that we should be using but haven't yet
instituted. And extending that to work with eggs also seems to make
sense. And then we avoid everyone having to add stuff to their spec
files
Err, that's why I said the motivation for this was that Dave Malcolm
wrote a script to do that for eggs :-)
If it's being done automatically, it's not really packaging policy --
it's just part of things working
The packaging policy portion is:
* Are Virtual Provides the way to go (I say yes and so far no one's shot
me down :-)
I don't really know how else you'd do it...
* What should the virtual provides be named?
Bikeshed :-) But the proposal matches what we do for everything else
* Should we do the part where we can only manage to pull Provides out
automatically but not Requires?
Obviously it'd be nice if we could get Requires done automatically too,
but it doesn't hurt to give the provides until then.
* Should we try harder to make subpackages listed?
How so? I might be missing something here but I don't see anything that
subpackages are especially relevant for? You mean like if a module is
split across subpackages?
So, eggs seem pretty straightforward to me. They establish what they
provide and what they depend on in their metadata. But the python()
namespace is not so easy. On the PackagingDraft/Python page I mention
that one thing we could try is to make a Provides: python(foo) for every
module in the site-packages directories. This is relatively
straightforward to automate but misses subpackages. The example I
brought up is bzr-gtk::
bzr has::
%{python_sitearch}/bzrlib
And so it Provides: python(bzrlib)
bzr-gtk has::
%{python_sitearch}/bzrlib/plugins/gtk
And in this scheme it wouldn't have any automated Provides.
Other bzr plugins can require that bzr-gtk is installed, though, so
they'll have to write their requirements on the package name instead of
a virtual provide.
Another example that's not so plugin/program based is toscawidgets. It
creates the directory: %{python_sitearch}/tw
Packages which create widgets that work within tosca can install into
subdirectories of that so this heuristic won't find them.
-Toshio
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Python Virtual Provides
