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
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 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/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 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/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
Re: Orphaning python-flit
On Thu, Jan 25, 2024 at 6:43 PM 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.
What is the *fascination* with splitting and renaming packages this
way? Ansible did this, and confused the heck out of their users by
shoving a hundred add-ons into "ansible" and leaving the actually
useful tools in "ansible-core". Why isn't the core packages left in
the original name for the package, and add-ons published as the
distinct package, rather than this apparently popular and breaking
change reverse procedure?
I've recently tried RHEL builds for these flit tools, and they
interweave badly with a circular build dependency involving of flit,
flit-core, flit-scm. setuptools-scm and exceptiongroups. The dodging
and weaving names of the base packages for their dependencies compound
the difficulties resolving these, at least resolving them from scratch
for RHEL backports.
> 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.
Agreed, especially considering the recent "bitcoin miner" burdened
modules published at pypi.org. It's very hard to maintain confidence
in a tool suite when any author of a module, upstream, may insert
quite baroque dependency chains.
>
> 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.
>
> --
> Maxwell G (@gotmax23)
> Pronouns: He/They
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
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.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
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.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
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
Orphaning python-flit
Hello.
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.
$ 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).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-flit
Hello.
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.
$ 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).
--
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
