#918 Please make an announcement on the use of new python packaging macros
Closed: fixed 2 years ago by churchyard. Opened 2 years ago by ankursinha.

(Not sure if this is the right place for this, but here goes)

I've come across the use of new python macros here recently:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/

However, these have not yet been announced to the community (well, not as far as I know). From my understanding of things, if these are ready for use by package maintainers, then they should be announced using the Change process and the python packaging guidelines updated to include their usage.

On the other hand, if they are not, then no package maintainers should be using them.

I.e., either everyone uses them, or no one does. Could the packaging committee please decide which one and inform the community?

From a response on the review where this came up: https://bugzilla.redhat.com/show_bug.cgi?id=1739786#c9

> There's also no mention of these macros in the python packaging guidelines---should we wait for them to be made public before using them?

They are currently experimental. If you use them, you should be prepared to follow the development and maybe adjust the package if we need to do any changes (though we'll try to not break stuff).

Based on this, my opinion is that these are not ready for use and so since they are also not in the python packaging guidelines yet, my current stance is to not approve packages that use them. Individual packager maintainers should not be expected to verify the correctness of such macros themselves.


either everyone uses them, or no one does

I don't agree. Those macros are provisional. Packagers who want to test them can use them if they are prepared to to get breakage.

The macros also wait for a new mock version, because the updates of mock got hit by negative karma based on a different error.

We are not yet ready for those macros to be wide spread. However there is AFAIK no rule that prohibits packagers to use macros not documented in the guidelines. If you are looking for the documentation of those macros, see https://src.fedoraproject.org/rpms/pyproject-rpm-macros README.

If we are to document this as part of the guidelines, then only as a reference to the README, as we don't want to wait on a committee every time we change the provisional macros.

either everyone uses them, or no one does

I don't agree. Those macros are provisional. Packagers who want to test them can use them if they are prepared to to get breakage.

Not really---once a package has been reviewed and included in Fedora, it still has to follow the packaging guidelines. Maintainers can't just deviate from them and do what they please. Even if we let that go what about reviews? What should one do there? Keep up with provisional macros? How does one verify their correctness, especially given that they are not ready for widespread use?

The macros also wait for a new mock version, because the updates of mock got hit by negative karma based on a different error.
We are not yet ready for those macros to be wide spread.

Yes, so packages and reviews are being used as a testing ground for these macros, but few are aware of this.

However there is AFAIK no rule that prohibits packagers to use macros not documented in the guidelines. If you are looking for the documentation of those macros, see https://src.fedoraproject.org/rpms/pyproject-rpm-macros README.

No. This is not fair :( Package maintainers spend their time keeping up with the guidelines. They cannot be expected to also follow ever changing provisional macros like this. The whole point of having a packaging committee that knows its stuff well set out guidelines is so that we can focus on knowing and implementing them well. When a change is made, we are notified via the devel list and so keep up with the new guidelines.

If we are to document this as part of the guidelines, then only as a reference to the README, as we don't want to wait on a committee every time we change the provisional macros.

Well, if you don't want to wait on a committee, you at least have to inform the people that are going to end up learning and using these macros. From whatever perspective you look at it, it is a big change and if not a change announcement, an e-mail about this should be sent out to the -devel list. Lots of people don't want to wait on a committee either, but there's a reason there's a change process in place that we all follow.

At the moment, only a handful of people are aware of these and the rest of the package maintainer body is going to find out about them when they unexpectedly run into them. That's not the right way of adopting new features.

There isn't a rule about this at the moment, but if macros are going to be changed without informing the package maintainers, maybe there should be one?

I see your point, but I don't agree with it completely. It is matter of opinion. Let's hear what others have to say.

I'd like to say that this is no change - a change would be if we ask people to use them. We are not doing that. We will put this into the guidelines before we do that.

``
I see your point, but I don't agree with it completely. It is matter of o=
pinion. Let's hear what others have to say.
=20
I'd liek to say that this is no change - a change would be if we ask =
people to use them. We are not doing that. We will put this into the guidel=
ines before we do that.

Sure, in that case, can a "Heads up" e-mail be sent out to the -devel
list informing the package maintainers of the availability of these
macros? That would be a good balance between "early adoption" and
"keeping people informed" IMO.

Works for me. Will draft something up.

Metadata Update from @churchyard:
- Issue assigned to churchyard

2 years ago

mock was updated in Koji.

I'll post some announcements once the recent updates reach stable:

https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros

Metadata Update from @churchyard:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata