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
