Hi,
I might be late and I haven't been to pycon but I've noted in this pep 345:
It is an attempt to re-invent the rpm spec file?
In this case how would you plan to integrate with the rpms dependecies?
Let me provide an usage scenario for packaging a generic rpm ("foobar"
from now on)
depending on another python module (let's call it "depend"):
1. user "build" his/her install a *local* version of "depend" in
order to build "foobar"
2. the building of the "foobar" rpm succeed because the "depend" is
installed (although locally)
3. "build" gives his rpm generated (and possibly the srpms) to the
network administrator
for deployment
At this point I see two problems:
1. the administrator installs "foobar" assuming that won't fail (runtime error)
2. the administrator tries to rebuild "foobar" from the srpm (build time error)
In both case the administrator will blame "build" because:
1. The developer relying on "foobar" cannot start it (missing
dependency "depend")
2. The administrator cannot rebuild "foobar" because "depends" is not installed
The problem is excacerbated by the fact that rpm has already a dependecy checker
(as yum/yast/smart and other tools make use of this) and it won't see
the "PKG_INFO"
dependencies.
Regards,
Antonio
On Thu, Apr 9, 2009 at 7:06 PM, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 7:31 PM, Tres Seaver <tsea...@palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziadé wrote:
>>> Jim started a branch during Pycon, maybe you can push your work over
>>> there for review here ?
>>
>> AFAICT, Jim hasn't checked anything into that branch:
>>
>>> $ svndiff
>>> http://svn.python.org/projects/peps/{trunk,branches/jim-update-345}/pep-0345.txt
>>> $ svn log --stop-on-copy
>>> http://svn.python.org/projects/peps/branches/jim-update-345
>>> ------------------------------------------------------------------------
>>> r70636 | jim.fulton | 2009-03-27 15:19:28 -0400 (Fri, 27 Mar 2009) | 1 line
>>>
>>> Update meta data reflecting work in setuptools
>>
>> I am not (yet) a Python committer; if I were so blessed, I would be
>> glad to commit this change on that branch.
>
> ok, maybe you can push it to the wiki then, and I'll commit it when it's
> ready ?
>
>>
>>> Also, I am wondering if we shouldn't merge it with PEP 376, where we
>>> might want to add a REQUIRES file
>>> into the egg.info structure, besides the PKG-INFO file.
>>
>> I wouldn't chunk those changes: the PEP which specifies the PKG-INFO
>> format needs to have a clear history.
>>
>> If PKG-INFO is extended to hold distribution-level requires / provides /
>> obsoletes, then I can see no reason to add another generated file inside
>> egg-info (which already contains PKG-INFO).
>
> Because setuptools does it. It adds a requires.txt file separated from
> PKG-INFO.
> But it would make sense not to have a second file.
>
> Tarek
> _______________________________________________
> Distutils-SIG maillist - distutils-...@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
