On Dec 1, 2016 6:58 AM, "Petr Viktorin" <pviktori(a)redhat.com> wrote:
On 12/01/2016 02:42 PM, Neal Gompa wrote:
> On Thu, Dec 1, 2016 at 8:36 AM, Igor Gnatenko <ignatenko(a)redhat.com>
>> On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava <torsava(a)redhat.com>
>>> On 11/30/2016 02:44 PM, Neal Gompa wrote:
>>>> On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava <torsava(a)redhat.com>
>>>>> I don't think the depgen should be enabled by default, at least
>>>>> foreseeable future. IIRC it's not that well implemented—e.g. I
>>>>> doesn't read requirements.txt for example
(but I might be wrong).
>>>>> There will be a lot of cases where the generated requirements are
>>>>> incomplete, or contain unnecessary entries, etc. I think it should
>>>> According to various Python people, we're not actually supposed to
>>>> read requirements.txt. That file is explicitly designed for people to
>>>> individualized deployments. The proper place to get this information
>>>> is from the egg-info/dist-info data, which is what we read. The fact
>>>> that some people abuse requirements.txt and have it read in by their
>>>> setup.py is beside the point. Whatever the setup.py (thus
>>>> pip/easy_install/etc.) says it needs, the generator will dutifully
>>> The fact remains in too many cases it will need to be manually
>>> won't be foolproof.
>>> Therefore I argue it would be better for it to be an opt-in so that new
>>> packagers don't immediately have to jump in into debugging a depgen
>>> have no clue how really works.
>> We'll see how it will go. we have depgen for pkgconfig, libraries,
>> etc. for many years and people don't go and debug it immediately, but
>> for many of packages it will help a lot. Anyhow, we'll see after
>> couple of releases.
>> Neal suggested to have:
>> in python.attr inside RPM.
>> I tested it and it just works once I specify `%global
>> pythondistdeps_enable 1` in spec. Can you help me to get this
>> included? With RPM part it's clear how to get this, but updating
>> guidelines and other stuff...
> This will also drastically simplify the work of tools like pyp2rpm,
> since instead of having to do crazy processing of module names, it can
> just use the appropriate pypi provides/requires. If the macro template
> enables the requires generator, it won't even need to specify requires
> at all, as they'll be generated from the wheel data anyway.
+1, ideally that'll leave us with only one automatic dependency generator.
Problems with upstreams getting setup.py wrong should be treated as
and treated accordingly: reported as pull requests, or, as
the last resort, by a Fedora-specific patch to setup.py.
Note that fedora will have to carry more patches to setup.py's (but
hopefully of limited durations and pretty trivial). Upstream versioned
requirements often don't match with distro packages because we backport to
work around bugs in compatible manners while upstream simply requires newer
versions that have the bugs fixed.
Not a showstopper by any means; just something to be aware of.