[Fedora-packaging] Python Virtual Provides

[Toshio Kuratomi]

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