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.
[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
