planning to orphan python-django (and a couple of dependent packages)
by Matthias Runge
Hello there,
you may or may not know, I have been maintaining python-django for quite
some time in the past, some time as part of my job. My role changed and
I really can not dedicate Django the time it deserves. I am looking for
someone or persons willing to take
- python-django
- python-django-angular
- python-django-appconf
- python-django-authority
- python-django-compressor
- python-django-contact-form
- python-django-debug-toolbar
- python-django-haystack
- python-django-mptt
- python-django-nose
- python-django-notification
- python-django-pagination
- python-django-pipeline
- python-django-piston
- python-django-pyscss
- python-django-rest-framework
- python-django-reversion
- python-django-robots
- python-django-tables2
- python-django-tagging
Matthias
2 months, 3 weeks
Python installation paths, pip, F36
by Owen Taylor
[ At Miro's request, resending this to python-devel so the discussion can
be public ]
Hi Miro -
When rebuilding a package to include in a Flatpak, we want to install
*everything* under prefix=/app - that includes Python modules. (Paths will
be adjusted properly when running the Flatpak.)
For years, the way we did that is by installing a
/usr/lib64/python3.10/distutils/distutils.cfg:
===
[install]
prefix=/app
===
This is part of the flatpak-rpm-macros package that gets installed in the
buildroot for Flatpak rebuilds
In Fedora 36, this no longer works for 'pip install' - it seems that pip
unconditionally uses 'sysconfig' rather than 'distutils' to determine
install paths for Python >= 3.10.
I see that you filed https://github.com/pypa/pip/issues/10647 which landed
in pip for pip-22, but Fedora 36 / pip-21 this isn't present? And in any
case, that seems like it's something for 'sudo pip install' rather than
package installation. I actually don't really follow how the Python macros
are getting things installed into /usr/lib rather than /usr/local/lib.
Any advice about how we can make the installation into /app work? Hopefully
in a future-proof way...
Thanks!!!
Owen
3 months, 2 weeks
Retiring Python 3.7 before Python 3.6?
by Miro Hrončok
Hey Pythonistas,
let me include you in my dilemma I have wrt different Python versions we
support in Fedora for testing.
tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for
RHEL 8, but 3.7 will no longer be "needed". However, retiring mid-order might
be confusing.
Note that this topic is not urgent at all, I am just curious about what is the
best plan for the future.
Python 3.7 retirement date
==========================
Python 3.7 has security support upstream until June, 2023.
It is also used in Debian 10 “Buster” -- LST ends June, 2024.
Ubuntu seem to have skipped this Python version, so no LTS to consider there.
Same with the SUSE Linux Enterprise Server.
If nothing changes significantly, Fedora 40 will be released in April 2024,
hence the natural thing to do would be to retire Python 3.7 in Fedora 40.
(I might have made an error, evaluating the dates. Please, do correct me if
there is a significant platform that supports Python 3.7 beyond Debian 10 LTS
EOL or if some dates are wrong.)
Python 3.6 retirement date
==========================
Python 3.6 will be supported until RHEL 8 goes EOL. Which will likely not
happen until 2029 [1]. That means, we might consider retiring it in Fedora 50
(wow).
My dilemma
==========
If we retire 3.7 before 3.6, the situation will be harder to explain to our
users. Why is there a gap, they might ask. In the future, the list of supported
Python versions might look weird and contain multiple gaps as we are eventually
going to face this situation again with 3.8, 3.10...
If we keep 3.7 around until 3.6 goes down, it will be harder to maintain. If it
was just 3.7, that would probably be acceptable, but assuming no release
schedules change, we will likely have Python 3.18 in Fedora 50. That means we
would need to support 12 different Python 3.X versions by then if we haven't
started introducing those gaps. Now we support 6.
As I written this down, I think the better thing to do is to accept the gaps
and retire Python 3.7 before Python 3.6 right away and not decide to "keep it
around, as we still support both 3.6 and 3.8". WDYT?
[1] https://access.redhat.com/support/policy/updates/errata
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 months, 4 weeks
Re: [EPEL-devel] %generate_buildrequires
by Orion Poplawski
On 12/3/20 14:06, Andrew C Aitchison wrote:
> On Thu, 3 Dec 2020, Michel Alexandre Salim wrote:
>
>>> Apart from the usual package-not-available story (which I want to fix
>>> as part of my work bringing up the EPEL Packagers SIG), my current
>>> snag is that python-tox-current-env uses %generate_buildrequires which
>>> does not work on CentOS 8:
>>>
>>> CentOS 8 is still on RPM 4.14:
>>> <mock-chroot> sh-4.4# rpm -q rpm
>>> rpm-4.14.2-37.el8.x86_64
>>>
>>> I'll put up a patch to hardcode dependencies for non-Fedora releases,
>>> though that sorts of defeat the purpose of dynamic build
>>> requirements.
>>> Then again, this is only needed for EPEL8, since EPEL9 will have a
>>> new enough RPM.
>>>
>> Given that %generate_buildrequires is the selling point of pyproject-
>> rpm-macros, I'm guessing a better way forward for EPEL8 would be to not
>> require it on EPEL8 since there's no way it would work, since RH won't
>> update RPM?
>>
>> https://src.fedoraproject.org/rpms/pyproject-rpm-macros
I've been playing around with a hacked version of pyproject-rpm-macros
which at least allows some basic functionality in EPEL8. Comments welcome.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/284
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
4 months
pyproject-rpm-macros 1.2.0: Improved support for alternate build
backends (e.g. hatchling)
by Miro Hrončok
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in
updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440
https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
What's new since 1.0.0
======================
Version 1.1.0 introduced support for nested directories in the *.dist-info
metadata directory. This was not needed before, as there was no known build
backend creating such directories. However, hatchling [1] does that and more
and more packages in Fedora are using it. This is a backward-compatible change
and you should not need to change anything unless you listed files in nested
directories manually -- this workaround can now be removed. The removal is
optional: if not removed RPM will only warn about files listed twice.
More importantly, version 1.2.0 added support for reading runtime dependencies
via %pyproject_buildrequires for build backends not supporting the PEP 517
prepare_metadata_for_build_wheel [2] (such as hatchling as well). Until now,
when you wanted to get the runtime dependencies (%pyproject_buildrequires -r:
the default) or use other functionality depending on it
(%pyproject_buildrequires -x/-t/-e) and the backend did not support it, it
failed -- you had to disable it by using -R.
However, PEP 517 explicitly says:
"""
If a build frontend needs this information and the method is not defined, it
should call build_wheel and look at the resulting metadata directly.
"""
%pyproject_buildrequires now provisionally support exactly that with the new -w
flag. When -w is used, the wheel is built and the macro looks at the resulting
metadata directly. Read all about it in the README [3] in the "Adding run-time
and test-time dependencies" section. A short tl;dr here:
- due to technical limitations, the wheel is built twice
- you can omit %build/%pyproject_wheel to avoid building it for the 3rd time
- don't patch/sed between %pyproject_buildrequires -w and %pyproject_wheel
- the -w flag builds the wheel even when the hook exists
As this is a provisional functionality, the API and/or behavior might change in
the future. Hence it is not yet mentioned in the packaging guidelines. You are
allowed to use it if you are prepared for potential breakage in the future.
Where to get help
=================
Report bugzillas [4] or write to this list [5] if you encounter any problems or
if you need help.
[1] https://pypi.org/project/hatchling/
[2] https://peps.python.org/pep-0517/#prepare-metadata-for-build-wheel
[3]
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/RE...
[4]
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pyproj...
[5] Fedora Python SIG <python-devel(a)lists.fedoraproject.org>
Happy packaging,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 months, 3 weeks
Splitting alternative Python packages into subpackages, e.g.
python3.11{,libs,devel,...}
by Tomáš Orsava
Hi Python-devel,
we are considering splitting the alternative Python versions from a
single-package format (e.g. python3.11) to multiple subpackages (e.g.
python3.11{,-libs,-devel,-tkinter,-test,-idle}). We do this already with
the main `python3` package: it requires less disk space to install and
speeds up download times, because you can chose which bits are important
to you. For example, if you decide you don't need python3-tkinter, you
save yourself ~18 dependent packages leading to a total savings of
~20MBs, while skipping python3-test saves you further ~10MBs.
What do you think?
The push came from [BZ#2063227] where the reporters would welcome to
have a smaller python3.11 package for containers and VMs for local
testing, CI purposes and more.
This would be a larger amount of work, so our initial reaction was
hesitant. We'll have to change the already complicated spec file %bcond
logic, and adjust the ecosystem to work with the new subpackages. For
example tox would need to Recommend `python3.11-devel`, as `python3.11`
would bring in only the bare interpreter. And of course a thorough
integration testing would be in order.
However, we already do separate subpackages for alternative stacks in
Enterprise Linux (CentOS /Stream, RHEL, EPEL) and as a general rule we
consider it good to have fewer differences between Fedora and EL. This
helps to test things earlier, and there are fewer surprises in user
experience. So perhaps the effort in doing this would be well spent.
To cut down on the amount of work, we're considering changing only the
`python3.11` package (and any future newer versions) right now. If later
we consider it worth it, we could switch the older alternative
interpreters as well, or we might let them die out as they are.
We're currently in the brainstorming stage, so you're feedback is welcome.
[BZ#2063227] https://bugzilla.redhat.com/show_bug.cgi?id=2063227
All the best,
Tomáš
4 months, 3 weeks
