From Fedora Project Wiki

Revision as of 16:13, 14 April 2009 by Dmalcolm (talk | contribs) (add link to the bug/script and some notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Virtual Provides

Dave Malcolm has proposed writing an rpm script to detect, at least, Python Eggs that are installed by a package. To go along with that, we should have virtual provides that map the package to egg name.

--Dmalcolm 16:13, 14 April 2009 (UTC): I wrote a script to try to auto-extract the Egg deps and turn them into RPM deps. This was in https://bugzilla.redhat.com/show_bug.cgi?id=451228 (mismatch between the numerous versioned deps in TurboGears' Egg file vs the RPM package). At the time I meant it more as a proof-of-concept experiment than a proposal for changing how we track python deps, but I'm happy if someone wants to take the idea and run with it.

--Dmalcolm 16:13, 14 April 2009 (UTC): note that there are some nasty syntax issues: e.g. Egg versions can contain dash characters, whereas RPM deps can't

We could copy the ruby/rubygem syntax and have something like this:

 Provides: python(bar) = %{version}
 Provides: python(foo) = %{version}
 Provides: pythonegg(foo) = %{version}
 Requires: pythonegg(foo) >= 0.3
 Requires: python(bar)

I think that Dave Malcolm's approach should be expandable to:

  • Providing normal python modules: look for them on the filesystem in site-packages.
  • Providing Python Eggs: Examine the egg info.
  • Requiring Python Eggs: Examine the egg info.

Requiring of normal python modules would still have to be done by hand (there's some ways this might be done but they're more complex). This also doesn't attempt to manage submodules of a normal python module: ie:

 bzr:
   %{python_sitearch}/bzrlib
   # Automatically found:
   Provides: python(bzrlib)
 bzr-gtk:
   %{python_sitearch}/bzrlib/plugins/gtk
   # Would have to manually specify:
   Provides: python(bzrlib.plugins.gtk)

My suggestion for this draft would be to specify submodules manually. Especially because some submodules will be necessary to specify while others will not (We shouldn't need to specify any submodules of bzrlib that are provided by bzrlib, for instance.)

If we don't want to convert packages to using Requires: python(bar) instead of Requires: python-bar because of the manual nature of the Requires, the pythonegg portion of this draft still has benefits.