Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 22, 2022 at 12:10:39PM +0100, Karolina Surma wrote:
On 11/15/22 12:42, Ewoud Kohl van Wijngaarden wrote:
On Tue, Nov 15, 2022 at 12:35:32PM +0100, Karolina Surma wrote:
On 11/15/22 08:37, Mattia Verga via devel wrote:
Il 15/11/22 00:23, Neal Gompa ha scritto:
On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
So let me sum up:

Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.
Upstream says that it is intended that packages are able to set their
version to 0 or 0.0.0, but…

Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.
… your proposed Change will fail those packages' build with no opt-out!? You
cannot be serious!

(Though actually, would %global __provides_exclude_from … together with a
manual Provides: python3dist(…) = 0 not work?)

A clear -1 to this Change as proposed.

We've never encountered a situation when packaging the version `0` was
the package maintainers intention.
What if it is the *upstream* maintainer's intention? Are we now dictating versioning schemes on upstream projects, disallowing version numbers that
upstream setuptools explicitly considers valid?

Unfortunately, I have to agree here. Nobody said we should be
dictating the versions for people. PEP-440 does not even make 0
version illegal, so this is unnecessarily punishing.

IMO, the policy is right, it just have to allow to opt out, so that the
maintainer is informed that **there could be** something wrong with the
package metadata / build process. Maybe an opt-out + file a ticket in BZ
to have track of the opt out, just like the ExcludeArch is the right
approach.

Mattia


Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?

I wonder how many Python packages have ever been packaged with version 0. Are we trying to solve a problem that doesn't exist?

Semver recommends[1] starting at 0.1.0 and without proof I think today most packages start by following semver. Any old packages that predate semver have a version > 0 by now.


Hi Ewoud,

Let me answer to two possible interpretations of your question.

The problem that exists is that you can incorrectly package a Python RPM with Provides = 0 (without even knowing it unless inspecting the metadata). I feel we could benefit from the proposed Change, if not for anything else, then by getting rid of unnecessary steps of discovery that a package is wrong (typically when it prevents other packages from building/running), opening a Bugzilla and working to fix it. That's costly and avoidable, so let's avoid it.

I'm 100% on board with that. Software should be hard to misuse and this looks like a case where it's hardly ever (possibly never) what the packager intended. That was not what my comment was about.

Does it happen that Python packages have a legitimate version 0 that should make it to Fedora? We don't believe so, hence the proposed Change, but as the others mentioned, it's not forbidden by PEP 440. setuptools and flit will let you create package with 0.0.0. Poetry automatically starts versioning the projects at 0.1.0.

That was indeed what my question was about. Yes, in theory a version 0 or 0.0.0 is possible but is there any proof that this is something that has ever been needed?

Providing an opt-out is trivial and if this is what makes the Change acceptable for the community, let's do it. It's definitely better than forcing people to opt out from the generators altogether.

I'd argue that any code has a cost, even if it's trivial. Code that's never executed is likely to be forgotten and/or have bugs.

So in short: this looks like a good proposal to me and I question the need for an opt-out.

[1]: https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux