This is a beautiful turn of phrase, but I would recommend sticking to a little bit simpler English in the guidelines: If you want to use ...

s/ vie / via/

As a personal preference, I always like to have a link to where this magical behaviour happens so that it can be debugged if necessary. Otherwise, it's really hard to find.

I think this merits an explanation for why the ~ are removed, perhaps:
[...] with any ~ characters removed (used for alpha/beta/dev versions in RPM versioning but not in Python versioning).

See individual commits.

@churchyard Could you provide a rendered version as well?

I can see some poor soul putting %py3_shebang_fix as the first line of the files, so I would be more explicit:

These shebangs MUST be fixed (for example by using the `+%py3_shebang_fix+` macro in the spec file).

Apologies for not quoting the relevant lines I'm replying to in my comments, as the line numbers will be changed when anything is pushed into the branch. I'll quote them from now on.

• |Given paths for Python files or directories with them, fixes Python shebangs to +%{__python3} -%{py3_shebang_flags}+. Preserves other existing flags if found.

If %{py3_shebang_flags} is empty, does it leave the trailing hyphen?

What if c+++ is released tomorrow? Since we want the current plus-ended packages to work, I don't see a reason to disallow new such packages to be created. Users will be confused why they can find some of them but not others under their official plussed-names.

• Fedora package names conventionally use + character

Fedora package names conventionally use the+character to separate the package name and the _extra_ name, e.g. the virtual package would be namedpython3-requests+security`.

• This is not the only way:

That sounds a bit weird in guidelines, I'd go with Alternative approach:

The macro takes the main package name and name(s) of the extra(s) as well as path to the .egg-info directory:

.dist-info or .egg-info directory.

Also, wouldn't it be better to have an example with dist-info?

For this case,
the extras dependency generator will read upstream metadata from the .egg-info directory.
If it finds that the extra requires on toml,
it will generate +Requires: python3.Xdist(toml)+,
+Provides: python3dist(setuptools-scm[toml])+
(and the corresponding +python3.Xdist+ variant).

The fact that the extra name and it's requirement are both named "toml" is very confusing, maybe a different example?

That concludes my initial review.

What if c+++ is released tomorrow? Since we want the current plus-ended packages to work, I don't see a reason to disallow new such packages to be created. Users will be confused why they can find some of them but not others under their official plussed-names.

This has been proposed by @pviktori. I would gladly allow pluses at the end without restrictions, the idea was that the rule (no pluses anywhere) is easier to explain (and remember).

Also, wouldn't it be better to have an example with dist-info?

The rest of the guidelines describe %py3_build/install -- and hence would have .egg-infos. So yes, we can say .dist-info or .egg-info but in the examples, I'd stick with the common case.

The fact that the extra name and it's requirement are both named "toml" is very confusing, maybe a different example?

Good point.

If %{py3_shebang_flags} is empty, does it leave the trailing hyphen?

No, this is a simplification. I wonder how to make it both simple and correct.

This is a beautiful turn of phrase...

By @dormouse. I've kept it, but you are right that something different might be better.

Thanks for the initial review. I'll incorporate it, but not today.
I agree with everything you've said, the only open questions are whether to allow + at the end unconditionally and how to express that the dash in shebang does not stay when the flags are empty.

What if c+++ is released tomorrow?

Same as when ¯\_(ツ)_/¯ is released tomorrow; you transliterate it to the allowed character set :)

If there really needs to be continuity between c++ and c+++, it's IMO reasonable to treat it as an “existing package with + at the end”. If you want to be extra formal, you can always ask FPC for an exception.

What if c+++ is released tomorrow?

Same as when ¯\_(ツ)_/¯ is released tomorrow; you transliterate it to the allowed character set :)

I thought the official transliteration of that package in Fedora was abrt? :smile:

If there really needs to be continuity between c++ and c+++, it's IMO reasonable to treat it as an “existing package with + at the end”. If you want to be extra formal, you can always ask FPC for an exception.

I respect that opinion, it is clearer to just ban all pluses, and let's be honest, the guidelines are long enough as they are. If you want to go in that direction, it's fine with me.

That being said, as a reviewer I feel strongly it is not the best choice. My issues with this:

• People will misremember and fail to remember that rule anyway.
• If we want to state that continuity packages are considered as existing packages, and that packagers can get an FPC exception, then it's getting complicated already.
• I feel like this is not enough justification to limit packagers choices and to introduce more inconsistency between Fedora and the wider ecosystem.

However, the main problem that I see is this:

• We're setting ourselves up for breaking users expectations from now on forever. I have currently 8 packages ending in a + on my system, many of which I know about, one of which (gcc-c++) many people know about. Unless we plan to rename those packages (and I hope we're not), we will forever have an inconsistency in naming and will baffle users trying to find their package.

If %{py3_shebang_flags} is empty, does it leave the trailing hyphen?

No, this is a simplification. I wonder how to make it both simple and correct.

How about:

Given paths for Python files or directories with them, it changes Python shebangs to +%{__python3}+, preserves any existing flags (if found) and adds flags defined in +%{py3_shebang_flags}+ (if not already present).

We're setting ourselves up for breaking users expectations from now on forever. I have currently 8 packages ending in a + on my system, many of which I know about, one of which (gcc-c++) many people know about. Unless we plan to rename those packages (and I hope we're not), we will forever have an inconsistency in naming and will baffle users trying to find their package.

Oh, for users you can add Provides: c+++. This is just about the package name.
It might be good to suggesting adding Provides with the +es – that would apply to all the packages with + in their name, not just the exceptions.

I'm +1, except points already raised.

I heard on the meeting that this is considered bikeshedding. I feel that when we're limiting other peoples' choices, we should have damn good justification for it, and it merits a discussion. But it seems I'm in the minority, no hard feelings.

We're setting ourselves up for breaking users expectations from now on forever. I have currently 8 packages ending in a + on my system, many of which I know about, one of which (gcc-c++) many people know about. Unless we plan to rename those packages (and I hope we're not), we will forever have an inconsistency in naming and will baffle users trying to find their package.

Oh, for users you can add Provides: c+++. This is just about the package name.
It might be good to suggesting adding Provides with the +es – that would apply to all the packages with + in their name, not just the exceptions.

That's a decent patch on this problem, but Provides don't work with a lot of tools/use cases, e.g. many dnf commands (for example dnf search), most repoquery commands, most rpm commands, etc. In my mind, not creating these problems is worth one more sentence in the guidelines.

I heard on the meeting that this is considered bikeshedding.

Sorry if that is not the case, It just feels that particular problem is receiving more energy than it is worth it. Let's finish the rest of the guidelines and than simply wait for more opinions?

My opinion leans towards what @torsava says. Pluses at the end work, so there is no technical reason to block them.

All review comments addressed, except for the + at the end of package names.

@torsava @pviktori A compromise proposal:

...Replace any + signs in the upstream name with -, or omit them when on beginning or end of the name. As an exception, + characters are permitted at the ends of the names in cases when the removal would cause a name conflict with another package name or user confusion.

If it finds that the extra requires cryptography,

The example looks good, I would make the wording a bit more obvious:

If it finds that the extras packagesecurityhas a dependency on a packagecryptography`,

...Replace any + signs in the upstream name with -, or omit them when on beginning or end of the name. As an exception, + characters are permitted at the ends of the names in cases when the removal would cause a name conflict with another package name or user confusion.

Fine by me.

I'd also be OK with just “…As an exception, + characters are permitted at the end of the name.”

I heard on the meeting that this is considered bikeshedding.

Sorry if that is not the case, It just feels that particular problem is receiving more energy than it is worth it. Let's finish the rest of the guidelines and than simply wait for more opinions?

My opinion leans towards what @torsava says. Pluses at the end work, so there is no technical reason to block them.

It's a peeve of mine, I feel the bikeshedding concept is sometimes used where it doesn't apply and it stifles discussion. I'm sorry if I sounded touchy about it.

...Replace any + signs in the upstream name with -, or omit them when on beginning or end of the name. As an exception, + characters are permitted at the ends of the names in cases when the removal would cause a name conflict with another package name or user confusion.

Fine by me.

I'd also be OK with just “…As an exception, + characters are permitted at the end of the name.”

Both sound ok to me.

I went through all the changes, they look good!

Pushed two fixups.

or omit them when on beginning of the name

Sorry, I missed this the first time, it should be "at the beginning".

The fixups look good!

Sorry, I missed this the first time, it should be "at the beginning".

Indeed. Amended to the fixup.

Fixups squashed based on the :thumbsup: on the previous comment.

+1

I'm +1 but I'm not sure what all the talk about + problems are ... you just defined a should std. for naming python packages, right? Why would c++ care or be affected?

c++ fortunately would not. But there other apps that happen to be written in Python and the packages are named with pluses: e.g. bout++, libkdtree++, sourcextractor++, nicotine+. Hence we agreed to keep that allowed.

LGTM, +1

(18:19:46) geppetto: #action Merge pr-1011 Python guidelines updates (+1:5, 0:0, -1:0)