python-flit for EPEL9?
by Michel Alexandre Salim
I'm starting to try and grok pyproject.toml and its assorted PEPs in
more details, and it looks like flit is one of the more straightforward
way to build compliant wheels out there.
Should we get it into EPEL9? I filed a tracking bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2035376
looks like it's retired in CS9 so it should be fine for us to have.
https://gitlab.com/redhat/centos-stream/rpms/python-flit/-/blob/main/dead...
It currently does not build because of some missing dependencies - I
listed them in the bug above - if we do want this in EPEL9 I'll file
those bug requests and make them block this.
Also, to note, the EPEL maintainer is currently set to orphan. While I'm
in python-sig so I can branch and build just fine as is, Miro, as the
owner could you add me to the ACL and/or set me as the EPEL assignee?
We could probably add epel-packagers-sig as collaborator on epel*
branches too.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
1 year, 9 months
Re: Are the new guidelines mandatory for new packages?
by Miro Hrončok
On 23. 12. 21 21:34, Robert-André Mauchin wrote:
> On 12/23/21 18:41, Miro Hrončok wrote:
>> On 23. 12. 21 18:25, Robert-André Mauchin wrote:
>>> Hello,
>>>
>>> Are the new Python guidelines mandatory or optional?
>>
>> Optional.
>>
>> From https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
>>
>> """Older guidelines are still being kept up to date, and existing packages
>> MAY use them instead of this document."""
>>
>
> I meant for brand new packages, when i review them, shall i ask people to
> follow the new ones strictly?
You might ask them nicely to consider it, but you should not demand that. They
are optional for brand new packages as well.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 9 months
Are the new guidelines mandatory for new packages?
by Robert-André Mauchin
Hello,
Are the new Python guidelines mandatory or optional? I mean the whole:
%build
%pyproject_wheel
%install
%pyproject_install
%pyproject_save_files
Or can packagers still use py3_build and py3_install?
Best regards,
Robert-André
1 year, 9 months
package request: PyWaffle
by Matthew Miller
Hi! I'm using this https://github.com/gyli/PyWaffle for some visualizations for Fedora Project stats.
I'm kind of out of the loop on the state of the art of python packaging, and wondered if some kind Python SIG person would like to take it on for me.
1 year, 9 months
suggestions for upstream and font bundling?
by Matthew Miller
I'd like to suggest to the PyWaffle dev that if system Font Awesome is
found, the package uses that (whether installed by RPM or pip or whatever).
What's a good way to do that?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 year, 9 months
(no subject)
by Matthew Miller
> My personal opinion is that packing Python libraries that are not required by
> packaged applications/tools brings very little benefit to the project. I suggest
> to use a Python virtual environment instead and install the libraries you need
> with pip.
In this case, it'd be really convenient, because I want to run a script that uses it in Fedora infrastructure, and this is the one not-currently-packaged dependency.
1 year, 9 months
Re: Recent python-pytest-cov update in F34/F35 causes many FTBFS
by Miro Hrončok
On 17. 12. 21 21:41, Adam Williamson wrote:
> On Thu, 2021-12-16 at 21:53 +0100, Miro Hrončok wrote:
>> On 16. 12. 21 20:09, Ben Beasley wrote:
>>> It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1] and
>>> F34[2]. I noticed this because, between my own packages and those maintained
>>> through @neuro-sig, I saw a wave of FTBFS notifications from Koschei.
>>>
>>> Unfortunately, because packages commonly pin a particular major version, and
>>> because pytest-cov has been in 2.x for a long time, a huge number of packages
>>> are likely to be affected.
>>
>> A good opportunity to patch/sed coverage out of those packages for good :)
>
> FWIW, I use a pattern in several projects I maintain where tests are
> always run via coverage, although actually generating and analyzing
> reports is only done in a tox environment that is run in CI workflows
> (and not in the package build). See:
> https://pagure.io/fedora-qa/fedfind/blob/main/f/tox.ini
> for e.g. If you have a better way to do this, let me know...
Something like this (untested).
[tox]
envlist = {py27,py36,py38,py39,py310,py311}{-coverage,},coverage-report
...
[testenv]
deps =
-r{toxinidir}/install.requires
-r{toxinidir}/tests.requires
coverage: -r{toxinidir}/tests-coverage.requires
commands =
python -m pytest {posargs}
[testenv:coverage]
commands =
coverage run -m pytest {posargs}
[testenv:coverage-report]
...
I would personally not mix coverage report and linting, but from downstream
perspective, it doesn't matter becasue that is what we don't run either way.
Also, if you don't like the repeated slightly different command, it can be
factored out, but I considered that less readable.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 9 months
