<br><br><div class="gmail_quote">On Mon, Jun 16, 2008 at 4:31 PM, David Malcolm <<a href="mailto:dmalcolm@redhat.com">dmalcolm@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Mon, 2008-06-16 at 15:56 -0400, David Malcolm wrote:<br>
> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote:<br>
> > I've added Python Virtual Provides to the list of draft guidelines.<br>
> ><br>
> > <a href="https://fedoraproject.org/wiki/PackagingDrafts/Python" target="_blank">https://fedoraproject.org/wiki/PackagingDrafts/Python</a><br>
> ><br>
> > There are two parts:<br>
> > 1) introduce virtual provides for python eggs.  Copying from the way we<br>
> > do rubygems, this would be:<br>
> ><br>
> > Provides: pythonegg(SQLAlchemy) = %{version}<br>
> > Requires: pythonegg(SQLAlchemy) >= 0.3.11<br>
> ><br>
> > 2) introduce virtualprovides for normal python modules:<br>
> ><br>
> > Provides: python(sqlalchemy) = %{version}<br>
> > Requires: python(sqlalchemy)<br>
> ><br>
> > The motivation for this is that David Malcolm (dmalcolm) wrote a proof<br>
> > of concept script to show how easy it would be to extract egg dependency<br>
> > information as part of the rpm build process.<br>
><br>
> I ran into various inconsistencies between the versions listed in the<br>
> egg requires.txt file and the rpm specfile, and thought that the latter<br>
> ought to be autogenerated from the former.<br>
><br>
> First pass at a script attached to bug 451228, and I posted this to<br>
> fedora-python-devel-list:<br>
> <a href="https://www.redhat.com/archives/fedora-python-devel-list/2008-June/msg00002.html" target="_blank">https://www.redhat.com/archives/fedora-python-devel-list/2008-June/msg00002.html</a><br>
><br>
> Obvious mistake I made was to try to store the mapping from python<br>
> modules to package names, instead, the script ought to generate some<br>
> kind of virtual provides as in Toshio's suggestion above.  Should be<br>
> simple to update the script<br>
<br>
</div></div>Implemented, attached to bug 451228.  This generates the following for<br>
the TurboGears egg (telling it to use the optional SQLAlchemy stuff):<br>
<br>
# Autogenerated metadata from "requires.py<br>
/usr/lib/python2.4/site-packages/TurboGears-1.0.4.4-py2.4.egg-info SQLAlchemy"<br>
Provides: pythonegg(TurboGears) = <a href="http://1.0.4.4" target="_blank">1.0.4.4</a><br>
Requires: pythonegg(CherryPy) >= 2.3.0<br>
Requires: pythonegg(CherryPy) < 3.0.0alpha<br>
Requires: pythonegg(DecoratorTools) >= 1.4<br>
Requires: pythonegg(FormEncode) >= 0.7.1<br>
Requires: pythonegg(PasteScript) >= 1.6.2<br>
Requires: pythonegg(RuleDispatch) >= 0.5a0.dev-r2303<br>
Requires: pythonegg(setuptools) >= 0.6c2<br>
Requires: pythonegg(simplejson) >= 1.3<br>
Requires: pythonegg(TurboCheetah) >= 1.0<br>
Requires: pythonegg(TurboJson) >= 1.1.2<br>
Requires: pythonegg(TurboKid) >= 1.0.4<br>
Requires: pythonegg(SQLAlchemy) >= 0.3.10<br>
<br>
Is the dash in the RuleDispatch version likely to cause problems?<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br><br>It shouldn't, provided the package which this lives in has a matching provides.<br><br>--<br>Jes <br></div></div><br>