subject:"Fedora 30 Self\-Contained Change Proposal\: Enabling Python Generators by default"

On Fri, Dec 28, 2018 at 7:21 PM Miro Hrončok  wrote:
>
> On 28. 12. 18 18:58, Avram Lubkin wrote:
> > On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko
> >  > > wrote:
> >
> > You can't make it work in EPEL easily because python modules do not
> > have pythonX.Ydist() provides.
> >
> >
> > Didn't realize that and not sure why that wasn't backported.
>
> Because stuff like this is not usually backported to already released RHELs.
>
> > Honestly,
> > if we aren't going to be consistent across EPEL and Fedora when we can,
> > then why are they even under the same umbrella?
>
> Fedora is newer than EPEL. EPEL is old. There will always be differences
> even if the project is under the same umbrella.
>
> > Anyway, looks like enabling it for EPEL is a bigger task. I still don't
> > see the point of enabling it by default in Fedora at this point.
>
> The point is to make Fedora packaging easier. Note the "Fedora" in this
> sentence. This will make future EL packaging easier as well, however not
> past ELs.
>
> > It can
> > easily be enabled for those who want it and doesn't add work for those
> > who it won't work for.
>
> It is now enabled. You can use it together with manual deps to maintain
> a single spec across EPEL and Fedora. I don't know what exactly is such
> a big deal here. It can also be easily disabled if you really like to.

Duplicated dependencies is a problem because rpm-md becomes larger. If
we would use Requires: python%{python3_version}dist() dependencies,
then RPM would merge them and it would be fine. But since we use
python3-foo and python3dist(foo), it makes duplicated dependencies.

So I'm just trying to send PRs to remove such deps.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 4:12 PM Miro Hrončok  wrote:
>
> On 28. 12. 18 22:10, Neal Gompa wrote:
> > On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok  wrote:
> >>
> >> On 28. 12. 18 18:58, Avram Lubkin wrote:
> >>> Especially since there is no test code!
> >>
> >> And this is the only thing when I agree with you.
> >>
> >> Neal, where would be the best place to add some tests for the generator?
> >> I can scratch something like [1] during next week.
> >>
> >
> > Tests belong in the rpm repository[1]. rpm itself uses autotest, so if
> > you want to wire the test into the existing framework, you can.
> > However, if we're going to have tests for dep generators, you might
> > want to place them in a subfolder in the tests directory[2] and wire
> > them into autotools.
>
> I can contribute tests. Tests is what I understand.
> But I would not dare to touch autotools, sorry.
>

You can make a subfolder and make a test file and ask for help to wire
it into autotools. I don't know how to do it either.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

2018-12-28 Thread Miro Hrončok


On 28. 12. 18 22:10, Neal Gompa wrote:

On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok  wrote:


On 28. 12. 18 18:58, Avram Lubkin wrote:

Especially since there is no test code!


And this is the only thing when I agree with you.

Neal, where would be the best place to add some tests for the generator?
I can scratch something like [1] during next week.



Tests belong in the rpm repository[1]. rpm itself uses autotest, so if
you want to wire the test into the existing framework, you can.
However, if we're going to have tests for dep generators, you might
want to place them in a subfolder in the tests directory[2] and wire
them into autotools.


I can contribute tests. Tests is what I understand.
But I would not dare to touch autotools, sorry.



[1]: https://github.com/rpm-software-management/rpm
[2]: https://github.com/rpm-software-management/rpm/tree/master/tests



--
真実はいつも一つ！/ Always, there's only one truth!



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok  wrote:
>
> On 28. 12. 18 18:58, Avram Lubkin wrote:
> > Especially since there is no test code!
>
> And this is the only thing when I agree with you.
>
> Neal, where would be the best place to add some tests for the generator?
> I can scratch something like [1] during next week.
>

Tests belong in the rpm repository[1]. rpm itself uses autotest, so if
you want to wire the test into the existing framework, you can.
However, if we're going to have tests for dep generators, you might
want to place them in a subfolder in the tests directory[2] and wire
them into autotools.

[1]: https://github.com/rpm-software-management/rpm
[2]: https://github.com/rpm-software-management/rpm/tree/master/tests



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 7:06 PM Avram Lubkin  wrote:
>
> On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko 
>  wrote:
>>
>> You can't make it work in EPEL easily because python modules do not
>> have pythonX.Ydist() provides.
>
>
> Didn't realize that and not sure why that wasn't backported. Honestly, if we 
> aren't going to be consistent across EPEL and Fedora when we can, then why 
> are they even under the same umbrella?
>
> Anyway, looks like enabling it for EPEL is a bigger task. I still don't see 
> the point of enabling it by default in Fedora at this point. It can easily be 
> enabled for those who want it and doesn't add work for those who it won't 
> work for. Especially since there is no test code!

Well, it has been opt-in since F28[0].

Automatic dependency generator actually fixes missing requirements
and/or wrong ones.

For instance, python-zeroconf was depending on `python3-six` and
`python3-netaddr` while the actual and only requirement was the
`python3-ifaddr`.

So it's already decided that we are going to enable them in F30+.
(Change was approved by FESCo and already turned on).

And yeah, patches (to add tests) are welcome.


[0] https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

2018-12-28 Thread Miro Hrončok

On 28. 12. 18 18:58, Avram Lubkin wrote:
On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko
> wrote:

You can't make it work in EPEL easily because python modules do not
have pythonX.Ydist() provides.

Didn't realize that and not sure why that wasn't backported.

Because stuff like this is not usually backported to already released RHELs.

Honestly,
if we aren't going to be consistent across EPEL and Fedora when we can,
then why are they even under the same umbrella?

Fedora is newer than EPEL. EPEL is old. There will always be differences
even if the project is under the same umbrella.

Anyway, looks like enabling it for EPEL is a bigger task. I still don't
see the point of enabling it by default in Fedora at this point.

The point is to make Fedora packaging easier. Note the "Fedora" in this
sentence. This will make future EL packaging easier as well, however not
past ELs.

It can
easily be enabled for those who want it and doesn't add work for those
who it won't work for.

It is now enabled. You can use it together with manual deps to maintain
a single spec across EPEL and Fedora. I don't know what exactly is such
a big deal here. It can also be easily disabled if you really like to.

Especially since there is no test code!

And this is the only thing when I agree with you.

Neal, where would be the best place to add some tests for the generator?
I can scratch something like [1] during next week.

[1]
https://github.com/rpm-software-management/rpm-extras/blob/master/brpscripts/Fedora/test_brp_mangle_shebangs.py

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> You can't make it work in EPEL easily because python modules do not
> have pythonX.Ydist() provides.
>

Didn't realize that and not sure why that wasn't backported. Honestly, if
we aren't going to be consistent across EPEL and Fedora when we can, then
why are they even under the same umbrella?

Anyway, looks like enabling it for EPEL is a bigger task. I still don't see
the point of enabling it by default in Fedora at this point. It can easily
be enabled for those who want it and doesn't add work for those who it
won't work for. Especially since there is no test code!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 12:38 PM Avram Lubkin  wrote:
>
> On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> Well, now that this has been enabled, it is likely that there already
>> are packages which make use of this functionality, and disabling the
>> generator again would break them. So reverting the changes doesn't seem
>> like a good idea. It'd also create even more chaos.
>
>
> It's just been a week so I doubt the impact is very large and the fix is 
> simply to explicitly turn on dependency generation. Igor and Neal are 
> championing this change, so I think if they can go back and work on the 
> missed steps, no reason to revert in rawhide, but if no one is signs up to 
> fix it, then it's clearly not ready.
>

No. This change has already been implemented in two other Linux
distributions for over a decade, Fedora is just late to the party. I
*know* it works well. There are a few fixes I need to make, and
they'll be made because Igor and I discovered some new corner cases,
but we wouldn't have found them unless we turned it on distro-wide.

>>
>> Maintaining single-spec compatibility with EPEL is the responsibility
>> of individual package maintainers that desire that. The changes to use
>> the generators are only done in "master", so before merging those
>> changes into the epel branches, the maintainers have the chance to add
>> the necessary conditionals or some other solution. (Alternatively,
>> disabling the generators in that specific package and continuing to
>> use the manual deps is also a valid option.)
>
>
> You seen to misunderstand how a common spec works. There are no changes made 
> between the branch merges. The purpose of this is to make it easier to 
> maintain packages across branches so packages don't languish unnecessarily. 
> Yes, it can be disabled per package, but isn't the point of this to save 
> effort. Seems like it just creates more work for other people.
>

You seem to misunderstand how this works. This change is not about
EPEL. For this context, I couldn't possibly care any less about EPEL.
If you are maintaining common specs across distributions, it is *your*
responsibility to account for the differences in the distributions.
Not mine. I gave you advice on how to handle the change. It's up to
you to implement it.

And before you think I don't care about EPEL at all, I maintain plenty
of packages in EPEL. And I know how to adapt my packages to deal with
changes. Heck, a good number of my packages are Fedora/Mageia/openSUSE
compatible, so I know how far to go for compatibility.

This has been opt-in for several Fedora releases already. There was
already a warning that this would change to be opt out in a future
Fedora release in Fedora 28. The whole point of this is to make it so
that this is the new baseline in Fedora.

This is *not* getting ported to EPEL unless the Red Hat Python team
wants to implement the necessary pieces in RHEL to make it work.

And for what it's worth, this is why we have branches in git
corresponding to release targets. If you don't want to deal with
supporting a common spec, don't. Use different ones for each target.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 6:46 PM Avram Lubkin  wrote:
>
> On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> Well, now that this has been enabled, it is likely that there already
>> are packages which make use of this functionality, and disabling the
>> generator again would break them. So reverting the changes doesn't seem
>> like a good idea. It'd also create even more chaos.
>
>
> It's just been a week so I doubt the impact is very large and the fix is 
> simply to explicitly turn on dependency generation. Igor and Neal are 
> championing this change, so I think if they can go back and work on the 
> missed steps, no reason to revert in rawhide, but if no one is signs up to 
> fix it, then it's clearly not ready.

Please specify what exactly you want us to fix.

>
>>
>> Maintaining single-spec compatibility with EPEL is the responsibility
>> of individual package maintainers that desire that. The changes to use
>> the generators are only done in "master", so before merging those
>> changes into the epel branches, the maintainers have the chance to add
>> the necessary conditionals or some other solution. (Alternatively,
>> disabling the generators in that specific package and continuing to
>> use the manual deps is also a valid option.)
>
>
> You seen to misunderstand how a common spec works. There are no changes made 
> between the branch merges. The purpose of this is to make it easier to 
> maintain packages across branches so packages don't languish unnecessarily. 
> Yes, it can be disabled per package, but isn't the point of this to save 
> effort. Seems like it just creates more work for other people.

I think it's you who misunderstand how people maintain their packages.
Some people do like you describe, but other people do maintain
different branches and don't blindly merge master to others.

Since this feature has been available since F28, I don't see any
reason why this has to be reverted. You can have same package across
all supported Fedora releases. This is **Fedora** change and if you
would like to implement this feature for EPEL, but this is not
something what me and/or Neal are going to do.

Moreover, it won't work there because pythonX.Ydist() Provides are
missing there and it totally depends on RHEL Python's team to
implement it and I have no control over there.

>
> Avram
>
>
> On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
>> > Looks like the dependency generator was turned on in rawhide. Igor has been
>> > making pull releases against packages because this is now creating
>> > duplicate requires for some packages. That would seem reasonable, but he
>> > never pushed the dependency generator to EPEL so packages which maintain a
>> > common spec file across branches require additional logic and it's creating
>> > more work instead of less work. The python-rpm-generators package doesn't
>> > even exist in EPEL. I started looking at what it would take to make it
>> > available, but the script that's used has no documentation and no tests.
>>
>> Well, now that this has been enabled, it is likely that there already
>> are packages which make use of this functionality, and disabling the
>> generator again would break them. So reverting the changes doesn't seem
>> like a good idea. It'd also create even more chaos.
>>
>> > I recommend we revert this to opt-in until a couple loose ends are tied up:
>> >  - Tests and a readme file are created for python-rpm-generators
>> >  - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
>> > (Requires python-rpm-generators RPM)
>>
>> Maintaining single-spec compatibility with EPEL is the responsibility
>> of individual package maintainers that desire that. The changes to use
>> the generators are only done in "master", so before merging those
>> changes into the epel branches, the maintainers have the chance to add
>> the necessary conditionals or some other solution. (Alternatively,
>> disabling the generators in that specific package and continuing to
>> use the manual deps is also a valid option.)
>>
>> Zbyszek
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedor

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

You can't make it work in EPEL easily because python modules do not
have pythonX.Ydist() provides.

On Fri, Dec 28, 2018 at 6:36 PM Avram Lubkin  wrote:
>
>
> On Fri, Dec 28, 2018 at 11:48 AM Neal Gompa  wrote:
>>
>> python-rpm-generators is not the real upstream for that code (rpm is).
>> And testability would be a bit difficult because all the script does
>> is pull stuff from python module metadata using setuptools and print it out.
>
>
> So you provide test data either as external files or using the the mock 
> Python module. This is pretty standard.
>
>>
>> It's not going to exist in EPEL because in RHEL, the Python dependency
>> generator doesn't exist at all. If we enabled it for EPEL, we'd have broken
>> dependencies everywhere, since no RHEL Python modules would have the
>> necessary generated dependencies. If you'd like to ask Red Hat to add it to
>> RHEL 7, be my guest. However, I suspect they'll say no.
>
>
> It doesn't need to be in the base, there just needs to be el6 and epel7 
> branches for python-rpm-generators and make it a dependency of
> python-rpm-macros which is also an EPEL package. This is relatively 
> straightforward. The only difference from Fedora is maybe it should probably 
> be opt-in instead of enabled by default.
>>
>>
>> A simple way to check if you should specify manually is to check if
>> %__pythondist_requires is undefined, like so:
>>
>> %if ! %{defined __pythondist_requires}
>> Requires: python3-modA
>> Requires: python3-modB
>> ...
>> %endif
>
>
> What is the point of this then if it requires additional logic and still 
> requires listing dependencies for EPEL? I'm happy to help with the changes 
> for EPEL, but I think if we're going to rely on this then it should at least 
> have tests.
>
> Avram
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Well, now that this has been enabled, it is likely that there already
> are packages which make use of this functionality, and disabling the
> generator again would break them. So reverting the changes doesn't seem
> like a good idea. It'd also create even more chaos.
>

It's just been a week so I doubt the impact is very large and the fix is
simply to explicitly turn on dependency generation. Igor and Neal are
championing this change, so I think if they can go back and work on the
missed steps, no reason to revert in rawhide, but if no one is signs up to
fix it, then it's clearly not ready.


> Maintaining single-spec compatibility with EPEL is the responsibility
> of individual package maintainers that desire that. The changes to use
> the generators are only done in "master", so before merging those
> changes into the epel branches, the maintainers have the chance to add
> the necessary conditionals or some other solution. (Alternatively,
> disabling the generators in that specific package and continuing to
> use the manual deps is also a valid option.)
>

You seen to misunderstand how a common spec works. There are no changes
made between the branch merges. The purpose of this is to make it easier to
maintain packages across branches so packages don't languish unnecessarily.
Yes, it can be disabled per package, but isn't the point of this to save
effort. Seems like it just creates more work for other people.

Avram


On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
> > Looks like the dependency generator was turned on in rawhide. Igor has
> been
> > making pull releases against packages because this is now creating
> > duplicate requires for some packages. That would seem reasonable, but he
> > never pushed the dependency generator to EPEL so packages which maintain
> a
> > common spec file across branches require additional logic and it's
> creating
> > more work instead of less work. The python-rpm-generators package doesn't
> > even exist in EPEL. I started looking at what it would take to make it
> > available, but the script that's used has no documentation and no tests.
>
> Well, now that this has been enabled, it is likely that there already
> are packages which make use of this functionality, and disabling the
> generator again would break them. So reverting the changes doesn't seem
> like a good idea. It'd also create even more chaos.
>
> > I recommend we revert this to opt-in until a couple loose ends are tied
> up:
> >  - Tests and a readme file are created for python-rpm-generators
> >  - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
> > (Requires python-rpm-generators RPM)
>
> Maintaining single-spec compatibility with EPEL is the responsibility
> of individual package maintainers that desire that. The changes to use
> the generators are only done in "master", so before merging those
> changes into the epel branches, the maintainers have the chance to add
> the necessary conditionals or some other solution. (Alternatively,
> disabling the generators in that specific package and continuing to
> use the manual deps is also a valid option.)
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 11:48 AM Neal Gompa  wrote:

> python-rpm-generators is not the real upstream for that code (rpm is).
> And testability would be a bit difficult because all the script does
> is pull stuff from python module metadata using setuptools and print it
> out.
>

So you provide test data either as external files or using the the mock
Python module. This is pretty standard.

> It's not going to exist in EPEL because in RHEL, the Python dependency
> generator doesn't exist at all. If we enabled it for EPEL, we'd have broken
> dependencies everywhere, since no RHEL Python modules would have the
> necessary generated dependencies. If you'd like to ask Red Hat to add it to
> RHEL 7, be my guest. However, I suspect they'll say no.
>

It doesn't need to be in the base, there just needs to be el6 and epel7
branches for python-rpm-generators and make it a dependency of
python-rpm-macros which is also an EPEL package. This is relatively
straightforward. The only difference from Fedora is maybe it should
probably be opt-in instead of enabled by default.

>
> A simple way to check if you should specify manually is to check if
> %__pythondist_requires is undefined, like so:
>
> %if ! %{defined __pythondist_requires}
> Requires: python3-modA
> Requires: python3-modB
> ...
> %endif
>

What is the point of this then if it requires additional logic and still
requires listing dependencies for EPEL? I'm happy to help with the changes
for EPEL, but I think if we're going to rely on this then it should at
least have tests.

Avram
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

2018-12-28 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
> Looks like the dependency generator was turned on in rawhide. Igor has been
> making pull releases against packages because this is now creating
> duplicate requires for some packages. That would seem reasonable, but he
> never pushed the dependency generator to EPEL so packages which maintain a
> common spec file across branches require additional logic and it's creating
> more work instead of less work. The python-rpm-generators package doesn't
> even exist in EPEL. I started looking at what it would take to make it
> available, but the script that's used has no documentation and no tests.

Well, now that this has been enabled, it is likely that there already
are packages which make use of this functionality, and disabling the
generator again would break them. So reverting the changes doesn't seem
like a good idea. It'd also create even more chaos.

> I recommend we revert this to opt-in until a couple loose ends are tied up:
>  - Tests and a readme file are created for python-rpm-generators
>  - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
> (Requires python-rpm-generators RPM)

Maintaining single-spec compatibility with EPEL is the responsibility
of individual package maintainers that desire that. The changes to use
the generators are only done in "master", so before merging those
changes into the epel branches, the maintainers have the chance to add
the necessary conditionals or some other solution. (Alternatively,
disabling the generators in that specific package and continuing to
use the manual deps is also a valid option.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

On Fri, Dec 28, 2018 at 11:35 AM Avram Lubkin  wrote:
>
> Looks like the dependency generator was turned on in rawhide. Igor has been 
> making pull releases against packages because this is now creating duplicate 
> requires for some packages. That would seem reasonable, but he never pushed 
> the dependency generator to EPEL so packages which maintain a common spec 
> file across branches require additional logic and it's creating more work 
> instead of less work. The python-rpm-generators package doesn't even exist in 
> EPEL. I started looking at what it would take to make it available, but the 
> script that's used has no documentation and no tests.
>

python-rpm-generators is not the real upstream for that code (rpm is).
And testability would be a bit difficult because all the script does
is pull stuff from python module metadata using setuptools and print it out.
It's not going to exist in EPEL because in RHEL, the Python dependency
generator doesn't exist at all. If we enabled it for EPEL, we'd have broken
dependencies everywhere, since no RHEL Python modules would have the
necessary generated dependencies. If you'd like to ask Red Hat to add it to
RHEL 7, be my guest. However, I suspect they'll say no.

> I recommend we revert this to opt-in until a couple loose ends are tied up:
>  - Tests and a readme file are created for python-rpm-generators
>  - The functionality is made available in EPEL6 and EPEL7 (opt-in ok) 
> (Requires python-rpm-generators RPM)
>

No. This functionality is not relevant to RHEL until a version of RHEL
includes it in the base. That will happen with RHEL 8, at which point
EPEL8 will have the functionality automatically. That's the whole
point of getting stuff like this done in Fedora first. This is why
this is a *Fedora 30 Change*.

A simple way to check if you should specify manually is to check if
%__pythondist_requires is undefined, like so:

%if ! %{defined __pythondist_requires}
Requires: python3-modA
Requires: python3-modB
...
%endif

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default