On Thu, Jan 25, 2024 at 6:43 PM Maxwell G <maxwell@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
