#740 Add "%python_enable_dependency_generator" onto Packaging:Python
Closed: accepted a year ago Opened 2 years ago by ignatenkobrain.

Working with wiki hurts me a lot, so here is draft:

Use `%?python_enable_dependency_generator` to automatically generate dependencies based on metada in egg/wheel (usually generated/installed as result of executing setup.py).

https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators


Also probably EPEL counterpart need to get warning that this is not supported there..

This needs more info:

  • Where do i put it?
  • (Ignore this) Should maybe be %{?python_enable_dependency_generator}... ?
  • Should mention that this doesn't work for distutils setup.pys and that setutptools (or compatible) are required.
  • Examples.

Where do i put it?

I think basically anywhere ;)

Should maybe be %{?python_enable_dependency_generator}... ?

%{?xxx} is same as %?xxx, matter of style... like we use %py3_build everywhere, not %{py3_build}..

Should mention that this doesn't work for distutils setup.pys and that setutptools (or compatible) are required.

Makes sense, though not sure how to describe this.

Examples.

Sure! Did you push python-notebook commit already? we could use it as an example.

%{?xxx} is same as %?xxx,

I haven't noticed the question mark before. My bad. Ignore that part.

Sure! Did you push python-notebook commit already?

https://src.fedoraproject.org/rpms/python-notebook/c/8598565ed85d19c289346bb200454b40b11a8465

There is a slight difference between the two.

%?xxx allows arguments to be passed in and processed as part of the macro. This is why so-called "command macros" do not typically have the curly braces around them.

%{?xxx} encapsulates the macro processing around the braces. For command macros, that would mean doing something like: %{mkrel 1} because %{mkrel} 1 will not work as expected.

My recommendation is that we should do %{?xxx} because we don't want to trigger weirdness with macro processing.

⋊> ~ rpm --eval "%?python_enable_dependency_generator foo"                                                                                                                                                 08:49:06

 foo
⋊> ~ rpm --eval "%{?python_enable_dependency_generator} foo"                                                                                                                                               08:49:19

 foo

but if you will try to do: %{?python_enable_dependency_generator foo}, you will get an error.

So I don't really care which method you pick up :)

Metadata Update from @ignatenkobrain:
- Issue assigned to ignatenkobrain
- Issue tagged with: writeup

2 years ago

This is tagged as writeup, but I don't see any indication that there was ever a vote on this. Moving to meeting so that we can talk about it.

I guess my primary question is that if it's OK for packages to enable this, then why isn't it just turned on by default? Certainly if we want people to test it, we should issue an announcement asking people to test it instead of modifying the packaging guidelines.

And I guess would should have been my primary question: Why is any action needed when this seems to be enabled by default already (in rawhide, at least) when python3-rpm-generators is installed?

Metadata Update from @tibbs:
- Issue untagged with: writeup

a year ago

It's enabled by default for F29+, but it's opt-in for F28 and older. So for targeting older releases, this needs to be known.

Metadata Update from @tibbs:
- Issue tagged with: hasdraft, meeting

a year ago

This needs to come up again at a meeting. I really don't know what state it's in.

Heh. So the state is: macro exists, it works fine for many packages.

OK, so I'll echo @churchyard's original comment here. There's not much of a draft here. If I were writing this up I wouldn't know where to put it. I think we need some description of what this does, or mention of the dependency generator somewhere in the python guidelines.

@churchyard: You're probably far better positioned to write something about this than I am.

For those following along at home, a comment above indicated that this is enabled in F29+. That is not true. It is not currently enabled by default anywhere, though a change proposal for that may be coming soon.

Metadata Update from @tibbs:
- Issue assigned to churchyard (was: ignatenkobrain)

a year ago

Metadata Update from @tibbs:
- Issue untagged with: hasdraft, meeting
- Issue tagged with: draftneeded

a year ago

@ignatenkobrain is there an explicit %?python_disable_dependency_generator I could recommend for people who know the generator would mess with the package?

@churchyard, unfortunately not yet. But that should be trivial to add.

I'll put it in the guidelines. Make sure to put it in the implementation once you do the f30 change.

Metadata Update from @churchyard:
- Issue untagged with: draftneeded
- Issue tagged with: hasdraft

a year ago

Metadata Update from @churchyard:
- Issue tagged with: meeting

a year ago

OK. Edited my comment with diff link.

True, we should be consistent even though personally I don't use the curly brackets when not absolutely required. After all, who writes ${FOO} in shell code when they could just write $FOO?

In fact, it might not be a bad idea to mention somewhere that the guidelines use brackets throughout for consistency, but it is acceptable to not use them when they are not necessary.

We talked about this at todays meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-09-06/fpc.2018-09-06-16.00.txt):

  • #740 Add "%python_enable_dependency_generator" onto Packaging:Python
    (geppetto, 16:24:45)

...there were +6 votes, and Igor wanted to add that people shouldn't just disable it if it doesn't work, but try and fix it. Neither of those made it into the notes though, sorry.

Metadata Update from @james:
- Issue untagged with: meeting
- Issue tagged with: writeup

a year ago

Announcement text:

A section covering the new automatic dependency generator was added to the Python guidelines.

Metadata Update from @tibbs:
- Issue untagged with: hasdraft, writeup
- Issue tagged with: announce

a year ago

Metadata Update from @tibbs:
- Issue untagged with: announce
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata