From Fedora Project Wiki

(python virtual provides)
(reformat)
Line 5: Line 5:
 
We could copy the ruby/rubygem syntax and have something like this:
 
We could copy the ruby/rubygem syntax and have something like this:
  
{{{
+
  Provides: python(bar) = %{version}
Provides: python(bar) = %{version}
+
  Provides: python(foo) = %{version}
Provides: python(foo) = %{version}
+
  Provides: pythonegg(foo) = %{version}
Provides: pythonegg(foo) = %{version}
 
  
Requires: pythonegg(foo) >= 0.3
+
  Requires: pythonegg(foo) >= 0.3
Requires: python(bar)
+
  Requires: python(bar)
}}}
 
  
 
I think that Dave Malcolm's approach should be expandable to:
 
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 normal python modules: look for them on the filesystem in site-packages.
* Providing Python Eggs: Examine the egg info.
+
* Providing Python Eggs: Examine the egg info.
* Requiring 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:
 
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:
bzr:
+
    %{python_sitearch}/bzrlib
  %{python_sitearch}/bzrlib
+
    # Automatically found:
  # Automatically found:
+
    Provides: python(bzrlib)
  Provides: python(bzrlib)
 
  
bzr-gtk:
+
  bzr-gtk:
  %{python_sitearch}/bzrlib/plugins/gtk
+
    %{python_sitearch}/bzrlib/plugins/gtk
  # Would have to manually specify:
+
    # Would have to manually specify:
  Provides: python(bzrlib.plugins.gtk)
+
    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.)
 
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.
 
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.

Revision as of 18:24, 16 June 2008

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.

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.