Re: Python Virtual Provides

[Toshio Kuratomi <a.badger@xxxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging