Re: Orphaning python-flit
Am 25.01.24 um 20:34 schrieb Miro Hrončok:
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
...
python-pydyf-0:0.8.0-1.fc40.src
...
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core
Indeed, python-pydyf and weasyprint build just fine with flit-core so I
changed that.
Felix
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
I patched python-signature-dispatch[1] and python-vecrec[2] so that they
now use flit-core. I’m glad you pointed out that they were using flit.
[1] https://github.com/kalekundert/signature_dispatch/pull/6
[2] https://github.com/kxgames/vecrec/pull/3
On 1/25/24 15:58, Maxwell G wrote:
On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:
Hello.
Hi Miro,
Thanks for the announcement!
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
For context, flit-core is the PEP 517 build backend that we need for use
with %pyproject_* in RPM builds. python3-flit provides the flit CLI that
can be used for basic Python project management (publishing to PyPI and
such). python3-flit and python3-flit-core used to be built from the same
SRPM, but we recently split it into two separate packages to simply the
specfile and help with RHEL builds.
While Python developers can always install the flit CLI with pipx or in
a virtual environment, it is nice to have a global version managed by
the system package manager.
I'll probably end up taking the package.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core (happy to help with that
if you are interested).
Regardless, those packages should switch to using flit-core to build.
Pulling in all of flit is not necessary for RPM builds.
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
Am Fr., 26. Jan. 2024 um 09:26 Uhr schrieb Miro Hrončok : > > On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: > > What is the*fascination* with splitting and renaming packages this > > way? > > No idea generally, but in the world of Python packaging, > the two cases I know (poetry, flit) were motivated by folks not wanting to > pull > in full-blown package and environment management apps when they only want to > pip install something that uses it. > > The split made a lot of sense. > > core - PEP517 backend https://peps.python.org/pep-0517/ > the rest - an app that let's you "manage" your project > > Scenario: > > - The developer uses the full app to create and develop the project. > - The user uses -core to build and install it. > > (Obviously a developer is free to just use -core as well, if they like it. > Many > upstream projects use flit-core only.) It makes a lot of sense also if you think about it this way: - packaging needs a solid base - developers and (typical fedora) users want the latest and greatest A split like in this case gives us both. I have the impression that we package way too much stuff which would be installed better on a per user base, such as many python and rust and go (and ...) packages and fonts. This leads to many interesting discussions and decisions about what kind of upgrade is right on Fedora and even EPEL. Michael -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: What is the*fascination* with splitting and renaming packages this way? No idea generally, but in the world of Python packaging, the two cases I know (poetry, flit) were motivated by folks not wanting to pull in full-blown package and environment management apps when they only want to pip install something that uses it. The split made a lot of sense. core - PEP517 backend https://peps.python.org/pep-0517/ the rest - an app that let's you "manage" your project Scenario: - The developer uses the full app to create and develop the project. - The user uses -core to build and install it. (Obviously a developer is free to just use -core as well, if they like it. Many upstream projects use flit-core only.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
