python-devel April 2020

python-devel@lists.fedoraproject.org

10 participants
18 discussions

review swap - python package
by Mukundan Ragavan 22 Apr '20

22 Apr '20

Hi all, Can someone please review this package for me? https://bugzilla.redhat.com/show_bug.cgi?id=1826998 This is python-language-server. This is, if I am not mistaken, the last package I need to update spyder to version 4.x I can review a package in return. Thanks, Mukundan.

1 0

Retire unused nose plugins?
by Miro Hrončok 21 Apr '20

21 Apr '20

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

2 4

Re: Co-Maintainers wanted for python-lockfile EPEL branches
by Miro Hrončok 20 Apr '20

20 Apr '20

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

2 1

Re: Co-Maintainers wanted for python-lockfile EPEL branches
by Miro Hrončok 20 Apr '20

20 Apr '20

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

1 0

Re: python3dist provides
by Miro Hrončok 20 Apr '20

20 Apr '20

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

1 0

Re: python3dist provides
by Miro Hrončok 19 Apr '20

19 Apr '20

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

1 2

Re: python3dist provides
by Miro Hrončok 19 Apr '20

19 Apr '20

On 19. 04. 20 2:16, Jerry James wrote: > What generates the python3dist(module) provides? I ask because I did > a build of python-nb2plots today for which those provides were not > generated: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1495361 > > even though they were for the previous build: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1449952 > > although with questionable values: > > python3.8dist(nb2plots) = 0+unknown > python3dist(nb2plots) = 0+unknown This: https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pyth… https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pyth… Let me try to debug it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 2

Current plan: Build python3, python3-libs etc. from python39 SRPM on F33+
by Miro Hrončok 06 Apr '20

06 Apr '20

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 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel April 2020