python-devel October 2019

python-devel@lists.fedoraproject.org

7 participants
5 discussions

Provisional pyproject RPM macros: Dynamic BuildRequires for Python packages
by Miro Hrončok 14 Nov '19

14 Nov '19

Hello fellow Python packagers. This is an announcement about a new set of RPM macros you can use to build PEP 517/518 enabled packages, that is Python packages that have the pyproject.toml file. https://www.python.org/dev/peps/pep-0517/ https://www.python.org/dev/peps/pep-0518/ https://snarky.ca/clarifying-pep-518/ The set of macros is designed for modern packaging with dynamic buildrequires in mind. The macros are in the pyproject-rpm-macros package and you can use them like this: BuildRequires: pyproject-rpm-macros %prep ... %generate_buildrequires %pyproject_buildrequires -t %build %pyproject_wheel %install %pyproject_install %check %tox See the full documentation of the macros: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/READM… See example spec files: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/tests (These use setuptools (setup.py), flit and poetry for build backends, but you cannot tell that from the specfiles - BuildRequires are generated dynamically from upstream metadata.) The macros are **provisional**, i.e. their API may be changed upon feedback received from you. We are not (yet) interested in a general "update all the Python packages" hunt, but rather in early adopters. If you have questions, ask here. We'll gladly extend the docs if something is not clear. If you find bugs, report them in bugzilla or here. Likewise for RFEs. Happy hacking, Python Maintenance

3 2

Building the python executable statically with libpython*.a for better performance
by Miro Hrončok 04 Nov '19

04 Nov '19

Hello, we've been recently approached by a colleague from Red Hat working on performance (CCed). According to their testing, Fedora Python performance could be improved by ~15% by building /usr/bin/python* statically with libpython*.a. That sounds like a worthy thing to do. https://bugzilla.redhat.com/show_bug.cgi?id=1749479 Since Python 3.8 Python extension modules are no longer linked to libpython.so and we can do the following: * build /usr/bin/python3(.8) statically with libpython*.a * build and ship libpython3.8.so.1.0 for packages that "embed" Python The change in the python3 package is trivial: https://src.fedoraproject.org/rpms/python3/pull-request/133 However it can have serious impact on Python extension modules that are linked to libpython3.8.so.1.0 by various "nonstandard" build mechanisms or by compiling code for Python extension module and code that embeds Python into one file. We will likely propose a Fedora 32 Change for this, however I'm opening this topic for discussion before we do so. Testing the proposed Pull Request with your code is also helpful. Let me know how can we make that easier (e.g. if you want a Copr or a Fedora 30/31 python38 package with this change). WDYT? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 6

case sensitive problems building packages (this case, PyVISA)
by Christopher Beck 20 Oct '19

20 Oct '19

Hi, I am trying to build PyVISA (https://pyvisa.readthedocs.io/en/latest/) using mock and the problem is, during the build it is looking for "/builddir/build/BUILDROOT/python-pyvisa-1.10.0-1.fc30.x86_64/usr/lib/python3.7/site-packages/pyvisa-1.10.0-py?.?.egg-info". But the real name if the directory is"/builddir/build/BUILDROOT/python-pyvisa-1.10.0-1.fc30.x86_64/usr/lib/python3.7/site-packages/PyVISA-1.10.0-py?.?.egg-info". So I think the developer was not aware of case sensitive systems. I tried to modify the specfile but with no different result. So original specfile was created using pyp2rpm. Besides PyVISA, I had this problem on some other python packages, too, so is there a way out of that except patching and rewriting stuff of the original python package? It seems to me like a common problem. I found [1] and pyvisa is mentioned there, but the problem seems to be the same (regardless to say I wonder how that guy there built this RPM of PyVISA). Best Regards Christopher [1]: https://github.com/fedora-python/pyp2rpm/issues/22

2 5

New Pythons in need for karma
by Miro Hrončok 18 Oct '19

18 Oct '19

Get Python 3.7.5 and 3.8.0 while they're hot: https://bodhi.fedoraproject.org/updates/?packages=python3&status=testing https://bodhi.fedoraproject.org/updates/?packages=python38&status=testing -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

django-pytest vs pytest-django
by David Moreau-Simard 09 Oct '19

09 Oct '19

Hi ! I'm working on a new package proposal for django-health-check [1] and one of it's test requirements is pytest-django. I naively attempted to use the python3-django-pytest [2] package in BuildRequires and soon noticed that the tests in %check would not pass. A bit of research later, I found out that there are projects named django-pytest [3] and pytest-django [4] on pypi. Great. The former is based on an upstream that hasn't been updated since 2012 [5] while the latter has been actively maintained [6]. Unless mistaken, we do not currently have a package for the maintained version, pytest-django. I guess the right thing to do would be to create a new package for pytest-django ? I don't have the bandwidth to take care of pytest-django right now. Would it be acceptable to propose a new package without %check until it gets packaged ? Thanks ! [1]: https://github.com/KristianOellegaard/django-health-check [2]: https://koji.fedoraproject.org/koji/packageinfo?packageID=13680 [3]: https://pypi.org/project/django-pytest [4]: https://pypi.org/project/pytest-django [5]: https://github.com/dusty-phillips/django-pytest [6]: https://github.com/pytest-dev/pytest-django

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel October 2019