Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2048097 - python3-py4j provides python3dist(py4j) = 0
Summary: python3-py4j provides python3dist(py4j) = 0
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: py4j
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Raphael Groner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: python3dist0
TreeView+ depends on / blocked
 
Reported: 2022-01-29 12:25 UTC by Miro Hrončok
Modified: 2022-11-11 15:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-11 15:31:33 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Miro Hrončok 2022-01-29 12:25:02 UTC 
The package python3-py4j has the following automatic provide:

  python3dist(py4j) = 0

It appears that the actual package version was lost during the packaging process. 

In most cases, this is caused by using a Source that misses version information, e.g. A GitHub tarball when the project uses setuptools_scm or pbr. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi

This bugzilla was created in a batch, so it does not have information about the exact cause for this package. If you need help figuring out why this happens in this particular package, feel free to ask.
Comment 1 Raphael Groner 2022-01-30 18:27:11 UTC 
I fail to see any relation to source tarball as there's definitely a version given as well in %prep to extract. 
To build, standard with macro %py3_build is used. Why setuptools_scm then as there's no BuildRequires for that?
Comment 2 Miro Hrončok 2022-01-30 21:02:58 UTC 
py4j-0.10.9/py4j-python3/setup.py:

VERSION_PATH = os.path.join("src", "py4j", "version.py")
# For Python 3 compatibility, we can't use execfile; this is 2to3's conversion:
exec(compile(open(VERSION_PATH).read(),
     VERSION_PATH, "exec"))
VERSION = __version__  # noqa
...
setup(..., version=VERSION, ...)


py4j-0.10.9/py4j-python3/src/py4j/version.py:

__version__ = ''


The build log has:

+ /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s'
WARNING: '' not a valid package name; please use only .-separated package names in setup.py
/usr/lib/python3.10/site-packages/setuptools/dist.py:507: UserWarning: The version specified ('') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.


The version is actually there in the tarball, but it is removed in %prep:

sed -i "s|'.*'|''|" %{name}-python/src/%{name}/version.py
Comment 3 Raphael Groner 2022-02-07 17:20:08 UTC 
Thanks for debugging. That hotfix to drop versionized jar file name was somehow implemented for ant, see comment in spec file. I can try to improve or find a better solution.
Comment 4 Ben Cotton 2022-02-08 20:08:27 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.
Comment 5 Raphael Groner 2022-03-08 21:47:45 UTC 
> The version is actually there in the tarball, but it is removed in %prep:

> sed -i "s|'.*'|''|" %{name}-python/src/%{name}/version.py

Well, that should not happen while package review, initially. But as comment tells this line is mostly for unversioned jar.
Comment 6 Karolina Surma 2022-11-11 15:31:33 UTC 
The package no longer creates an incorrect automatic provide.
Note You need to log in before you can comment on or make changes to this bug.