python-devel January 2022

python-devel@lists.fedoraproject.org

9 participants
8 discussions

Should python3dist(...) provides generator fail when the version is = 0?
by Miro Hrončok 07 Feb '22

07 Feb '22

Hello Pythonistas, today, I've looked up packages in rawhide providing python3dist(...) = 0 and I opened bugzillas for them: https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 While version 0 (or equal versions like 0.0 or 0.0.0) is probably technically valid, it most certainly indicates a packaging error (most likely but not necessarily a downstream packaging error). Should we prevent this error from happening by explicitly erroring (and failing the build) when it happens? I think it would make the dependency generators more robust. In an unlikely scenario when packagers actually want to package version 0, they can reach out and we can allow it via some configuration (but [YAGNI], so I don't want to clutter the generator with yet another option right away). [YAGNI] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 3

MinGW & building wheels
by Scott Talbert 21 Jan '22

21 Jan '22

Hi all, Does anyone have any experience with using Fedora's MinGW stack to cross-compile Python wheels for Windows? Scott

3 3

question about review process excemptions for Python 3
by Felix Schwarz 21 Jan '22

21 Jan '22

Hi, the packaging guidelines have a few excemptions for the package review process [1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129, [2]). I need some additional Python 3 packages in EPEL 7 to achieve that and my question is which of these packages should get a proper review. A) python3-augeas https://bugzilla.redhat.com/show_bug.cgi?id=2043744 This is mostly the Fedora spec with just on additional bugfix (already upstream). B) python3-josepy intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-… I did not want to upgrade the existing EPEL 7 package as the required version is Python 3 only. We can not use some newer macros like %pytest but otherwise the spec is the same as in Fedora. C) python3-boto3 python-boto3 (Python 2) version is in RHEL and won't get a Python3 package. intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-… The spec file is very close to the RHEL spec file just with some customizations removed. Should I try to get reviews for each of the three packages or can I skip some of these according to the Fedora review policy? Felix [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797129

1 0

Undoing my screw-up with python-async-timeout
by Paul Wouters 19 Jan '22

19 Jan '22

Hi, I screwed up python-async-timeout in Fedora 34 by pushing it from 3.x to 4.x. I should not have bumped the major without significant more testing and talking to people. I rushed it through and caused lots of breakage. So first, I really do want to apologise for the mess I caused. And I'll make sure it won't happen again. I will do some community service by doing a bunch of outstanding package reviews we currently have open. The biggest issues is breaking python-aiohttp. I've spend some time in looking at bumping python-aiohttp to 3.8.x to match it up with python-async-timeout 4, but both the python-aiohttp test cases fail as well as my own $dayjob code using it. There are a four more (known) packages that fail based on the API change that could probably be fixed, but there would also be other python code outside fedora that might fail on the API change. And since my attempted use of the newer version of python-aiohttp in fedora 34 is also causing issues, I think the safer choice is to roll back python-async-timeout from 4.x to 3.x using Epoch. An alternative could be to fixup python-aiohttp 3.7.x to work with async-timout 4.x, but that still involves two API changes inflicted on others as well: - Support timeout.deadline - Port timeout.timeout property that returns a relative timeout based on the timeout object creation time to the absolute timeout.deadline instead. Although possibly a wrapper patch could be written to handle this to give 3.x API compatibility back. But it would still require package requirements that require < 4 to be respun to allow version 4. Another alternative is to investigate why python-aiohttp 3.8.x %check fails on wait_from() et all in f34/f35 but not in rawhide and port what is needed there back to f35/f34. I looked at this briefly, and it is not clear to me what is failing, and I would need help to look into this. I do think undoing python-async-timeout with an Epoch is ugly but the best path forward. I think due to the pythondist specific requires, we would not need to carry the epoch into f35 or rawhide to preserve EVR? I am looking for some guidance to ensure I don't break things even more and I apologise for the extra work that I have and am causing everyone. Paul

2 2

Proposal: Make -r (include runtime deps) the default for %pyproject_buildrequires
by Miro Hrončok 19 Jan '22

19 Jan '22

Hello Pythonistas. When we invented the %pyproject_buildrequires BuildRequires generator, it generated build-dependencies. Imediatelly we realized that for several reasons, also generating the runtime dependencies as BuildRequires is needed: - they are needed to run the test suite - they are needed to run an import check - they make the build fail when runtime dependencies are not found Hence, %pyproject_buildrequires -r was introduced. This flag is implied by other flags (-x, -t, -e) but it is not a default behavior. However, as I've done a fair amount of new package reviews and pull request reviews to convert packages to pyproject-rpm-macros, I've noticed packagers have a tendency to forgot the -r flag when: 1) The currently packaged version has no runtime dependencies. This is currently quite harmless, as when the package is updated with new dependencies, the packager will notice and add the flag. However, if we ever have some automation for updates, we better have forward-compatible specfiles. 2) The runtime dependencies are pulled in as transitive dependencies of manually BuildRequired packages. For example, if there is `BuildRequires: python3-pytest` and the package runtime-requires toml, the tests will suceed with pytest 6 (requires toml) but will error with pytest 7 (as it migrated from toml to tomli). 3) There is not a single check run in %check. While technically forbidden by the new guidelines, this is not enforced and hence packages use %pyproject_buildrequires but don't run any tests. This can result in packages that are updated into an uninstallbale state. I'd rather the build failed in that case. Hence, I propose we make the -r flag the default. In case some package needs to opt-out for legitimate reasons, a new flag would exist to disable it (most likely -R). While technically a backwards-incompatible change, I belive the negative impact should be minimal -- at worst packages that fail to install will now also fail to build (which is a good thing IMHO). Thoughts? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 7

Re: [Python-Dev] [PSA] OpenSSL 3.0 support is preliminary and experimental
by Miro Hrončok 10 Jan '22

10 Jan '22

On 09. 01. 22 19:39, Christian Heimes wrote: > Hi, > > I would like to remind everybody that Python's support for OpenSSL 3.0 is > preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda > works. However there are known performance regressions, missing features (e.g. > usedforsecurity flag), and potential bugs cause by API incompatibilities. > > Due to the experimental state I advise against using Python with OpenSSL 3.0 in > production. > > It may take a while until Python gains full support for the next version of > OpenSSL. I have shifted my personal OSS time to more fun topics like > performance and WASM. My work time is currently limited, too. Hello Christian. Do you think we should switch Python in Fedora 36 to OpenSSL 1.1.1? Python was naturally rebuilt with OpenSSL 3.0 when the distro upgraded OpenSSL. But the older version is still available. Note that Fedora 36 is also "preliminary" so we still have time to make this decision until +- the beta freeze/release (end of February, early March this year). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

PyPy3.8 now available
by Miro Hrončok 07 Jan '22

07 Jan '22

Hello Pythonistas. PyPy3.8 is now available in Fedora. On rawhide, when you dnf install pypy3, or when you run the pypy3 command, you will get PyPy3.8. PyPy3.7 is still available for the time being (pypy3.7 package and command). On Fedora 35, when you dnf install pypy3, or when you run the pypy3 command, you will still get PyPy3.7. pypy3.8 package will be available from updates testing when the build finishes and I'll create the bodhi update. On Fedora 34, when you dnf install pypy3, or when you run the pypy3 command, you will still get PyPy3.6. pypy3.8 package will be available in updates testing soon: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e29bfb393 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

Fwd: Python SIG at Fedora Council Video Meeting
by Miro Hrončok 06 Jan '22

06 Jan '22

Hello, does anybody want to take this? If not, I will. -------- Forwarded Message -------- Subject: Python SIG at Fedora Council Video Meeting Date: Thu, 6 Jan 2022 16:06:17 -0500 From: Tom Callaway <spotrh(a)gmail.com> To: Miro Hrončok <mhroncok(a)redhat.com> Miro, I know you're in the Python SIG, please forward this on as needed. The Fedora Council would like to invite your SIG to present at an upcoming Fedora Council video meeting. If you're interested, what we'd be looking for from you is: * Someone to present (on camera in a virtual meeting room) a 10-15 minute presentation (with slides) on the state of your SIG (past, present, future) along with any calls to action that you might have. * Stick around for 15+ minutes for Q&A discussion These meetings are recorded and then shared on youtube:https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow <https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow> A small FAQ: Q. When are these meetings held? A. The video meetings are held monthly, on a Thursday, between 1800 - 1900 UTC. Q. Do we have to do this? A. No. It is an opportunity we're making available to you, but if you don't want to (or cannot), feel free to decline (or ignore this email). Q. Would the meeting be all about our SIG? A. We also use some time to discuss council business, but you'd be the guest(s) of honor. Q. Okay, we're in. How do I sign-up? A. You reply to this email and say "Our SIG would love to do this!" and I'll get you scheduled. Q. I have other questions, who can I ask? A. You can ask me! You now have my email, or you can find me any of the other obvious places I have presence on the internet and ask me there. Thanks, Tom "spot" Callaway, on behalf of the Fedora Council

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel January 2022