Retire unused nose plugins?
by Miro Hrončok
Hello.
Given https://fedoraproject.org/wiki/Changes/DeprecateNose would you be OK if I
retire python-nose_fixes, python-nose-xcover and python-nose-testconfig in rawhide?
Nothing in Fedora depends on them:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-nose_fixes
$ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-xcover
$ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-testconfig
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
Re: Co-Maintainers wanted for python-lockfile EPEL branches
by Miro Hrončok
On 20. 04. 20 13:45, Fabio Valentini wrote:
> and it seems I
> can't even figure out how to determine which EPEL packages require
> python*-lockfile.
Take the attached repo files.
They are good for repoquery, adapted from epel-release.
They don't have -testing repos, but -testingx, so you don't accidentally enable
them with dnf --enablerepo=\*-testing.
Usage:
$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
Re: Co-Maintainers wanted for python-lockfile EPEL branches
by Miro Hrončok
On 20. 04. 20 15:24, Troy Dawson wrote:
> On a RHEL8 machine, doing a
> dnf repoquery --whatrequires python3-lockfile
> dnf repoquery --whatrequires python2-lockfile
> Shows that the following depend on it
> duplicity
> python3-fedora
> pungi-legacy
>
> I haven't checked EPEL7 yet.
$ repoquery --repo=epel7{,-source} --whatrequires python3-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python2-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python-lockfile
atomicapp-0:0.6.3-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.src
duplicity-0:0.7.19-1.el7.x86_64
pungi-0:3.12-3.el7.1.noarch
python-daemon-0:1.6-4.el7.noarch
python-daemon-0:1.6-4.el7.src
python-fedora-0:0.10.0-1.el7.src
python2-fedora-0:0.10.0-1.el7.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
Re: python3dist provides
by Miro Hrončok
On 19. 04. 20 18:01, Jerry James wrote:
> On Sun, Apr 19, 2020 at 10:00 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 19. 04. 20 17:49, Miro Hrončok wrote:
>>> On 19. 04. 20 17:09, Miro Hrončok wrote:
>>>> I'll send a PR shortly.
>>> Finishing the commit message...
>>
>> https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2
>
> Thank you!
You are welcome and sorry for the trouble with the broken generator -- although
it uncovered a problem in nb2plots.
As a side note I must say I really dislike how versioneer hardcodes the version
information in the file with bundled copy of versioneer itself.
There is at least https://github.com/warner/python-versioneer/issues/199 for
environment variable support.
But latest commit in the project is from 2017.
If you have close relationship with nb2plots upstream, please consider
suggesting them to switch to setuptools-scm, the de-facto standard to do what
versioneer is doing (however I don't know the history, maybe they have chosen
versioneer over setuptools-scm for a reason).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
Re: python3dist provides
by Miro Hrončok
On 19. 04. 20 16:39, Jerry James wrote:
> On Sun, Apr 19, 2020 at 2:11 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> Correction, this is valid:
>>
>> https://www.python.org/dev/peps/pep-0440/#local-version-identifiers
>>
>> But in this package case, we don't want version 0, so valid, but wrong.
>>
>>
>> Followup on the generator problem:
>>
>> https://github.com/rpm-software-management/rpm/issues/1183
>>
>> - the traceback should say: Cannot process Python package version: 0+unknown
>> - the build should abort on errors
>> - the version is actually valid
>
> Thanks for the detective work, Miro. I wish this upstream would just
> release a new version.
>
> Anyway, now that I know what the immediate problem is, I'll try to
> work around it. Regards,
In this particular case the version is trying to be read from git, I recommend
using %autosetup -S git and creating a %{version} tag in %prep.
I'll send a PR shortly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
Current plan: Build python3, python3-libs etc. from python39 SRPM on
F33+
by Miro Hrončok
Hello Pythonistas.
(I've CC'ed the devel list for further exposure. But let's discuss this on
python-devel list please to avoid noise.)
We would like ro rename the "python3" component (SRPM) to "python39" to make
maintaining various Python versions in various Fedora versions easier.
The names of binary RPMs would be unchanged; you still do `dnf install python3`.
The change should only affect packagers of Python itself; not users or packagers
of software written in Python.
The only user-visible or general-packager-visible change is a different
component (SRPM) name.
Details follow.
Currently, we build the Python interpreters this way:
- the "main" Python 3 interpreter component is called python3
- it builds a couple of subpackages, like python3-libs or python3-devel
- the "alternate" Python 3 versions components are called python3X (python37,
python39...)
For example, Fedora 31 has:
- python36
- python3 (the "main" Python, which is 3.7.x)
- python38
- python39
(python37 is retired in f31, but present in Fedora versions where python3 != 3.7)
This makes updating the "main" Python fairly complicated. To upgrade from 3.7 to
3.8 in f32, we had to:
1) retire python38
2) upgrade python3 from 3.7 to 3.8 (this makes python3 obsolete python38)
3) re-introduce (unretire) python37
Such an update comes every few years:
- https://fedoraproject.org/wiki/Changes/Python3.7 (f29)
- https://fedoraproject.org/wiki/Changes/Python3.8 (f32)
- https://fedoraproject.org/wiki/Changes/Python3.9 (f33)
What's even more complicated is backporting patches across Fedora releases.
Assume there is an important upgrade/fix for Python 3.7 we wish to apply for all
Fedoras including stable. That currently means we need to apply the fix in:
- master branch of python37
- f32 branch of python37
- f31 branch of python3 (!)
- f30 branch of python3
While cherry-picking or merging patches between branches of one git repo is
quite straight-forward (the only major obstacle is the release and %chaneglog),
doing this across multiple git repos (and spec filenames) is very tedious and
error-prone (albeit possible).
With the 3.9 update approaching in Fedora 33, we would end up with the following
scheme when updating Python 3.8:
- master branch of python38
- f32 branch of python3 (!)
- f31 branch of python38 (!)
- f30 branch of python38
Apart from technological obstacles, this causes nontrivial cognitive overhead.
So far, I've been carrying that overhead myself, but others (who don't work on
the Fedora Python packages daily) always need my assistance with this, because
it's overly complicated and hard to understand without drawing pictures.
For this to be easier for us, while keeping the change minimal for others, we
have decided to retire the python3 component and only continue maintaining the
interpreters in "python3X" components. The names of "binary" packages remain
unchanged.
Before:
SRPM: python3
builds:
- python3
- python-unversioned-command
- python3-{libs,devel,tkinter,idle,test,debug}
- python3-debug{info,source}
After:
SRPM: python39
builds:
- python3 (unchanged)
- python-unversioned-command (unchanged)
- python3-{libs,devel,tkinter,idle,test,debug} (unchanged)
- python39-debug{info,source} (usually not installed by name)
To avoid further confusion, the "python3-libs" etc. packages will provide
"python39-libs" as well.
We plan to do this together with the Python 3.9 upgrade. I'll update the change
page after some feedback happens here.
The initial implementation is in:
https://src.fedoraproject.org/rpms/python39/pull-request/32
Here are other approaches we have considered:
Why not rename the packages to python39-libs etc. (and only provide python3-libs)?
This would be inconsistent with the way other Python 3 packages are called
(e.g. python39-setuptools). We consider that confusing.
The goal here is to make our work easier while introducing minimal changes to
our users and contributors.
Why not rename all the Python packages to python39-setuptools etc.?
This would create a mess upon distro boundary Python upgrades.
All python39-foo packages would need to obsolete all python38-foo packages.
Even if we add the obsoletes metadata to all the packages, it would prevent
users from having the two parallel stacks of Python installed on the same OS.
(We don't have such stacks in Fedora, but we intend to continue to make this
possible in third party repos, downstreams of Fedora or other systems built on
top or Fedora).
See also the "minimal changes" point above.
Why not package the alternate stacks as modular streams and keep everything
called just python3- (or even python-)?
1) The Python stacks are naturally parallel-installable. This would not be
possible if they were different streams of one module.
2) Vital system tools (dnf, anaconda, packaging tools) use Python, so the
"main" Python can't be in a module. (We could solve this by a separate
"platform Python" just for these system tools, but that makes everything more
complex and harder to work with -- the opposite of what this change is about.)
See also the "minimal changes" point above.
Why are you breaking the world once again?
Sorry if this breaks anything for you. Could you be as specific as possible?
We anticipate no changes in Fedora packages (other than python3/python39).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years
