[Fedora-packaging] Python Virtual Provides
Toshio Kuratomi
a.badger at gmail.com
Tue Jun 17 10:37:33 UTC 2008
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20080617/7e8bb448/attachment.bin
More information about the packaging
mailing list