On Sun, 16 Jan 2022 at 07:23, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 16. 01. 22 12:49, Andrew C Aitchison wrote:
> On Sun, 16 Jan 2022, Miro Hrončok wrote:
>
>> On 15. 01. 22 20:22, Andrew C Aitchison wrote:
>>> On Sat, 15 Jan 2022, Miro Hrončok wrote:
>>>
>>>> python-pytest-cov is something I've lobbied has no business in an
>>>> enterprise distro at all.
>>> ... ...
>>>> As for EPEL I strongly suggest not to introduce python-pytest-cov either.
>>>> If your package depends on it, please drop the dependency instead, see
>>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters
>>>
>>> In %check, packages SHOULD NOT run “linters”: code style checkers, test
>>> coverage checkers and other tools that check code quality rather than
>>> functionality.
>>> Agreed.
>>>
>>> Linters do make sense in upstream CI. But not in Fedora.
>>> Not inside Fedora *packages*, but
>>> if these tools are not available to those using RHEL, Fedora or EPEL
>>> is that a suitable platform for CI or for developers ?
>>>
>>
>> Yes, most certainly it is a sustainable *platform* for CI. On such platform,
>> you install your dev-dependendencies from PyPI. Not from the platform itself.
>
> Hmm.
> A linter is a tool.
> I cannot build most packages without a C compiler and I don't see many packages
> with
> BuildRequires: gcc
> yet I expect a dev platform to include a C compiler.
I do expect a dev platform to include a C compiler as well.
I also expect it includes Python interpreter and a tool to install Python packages.
I *do not* except it to include every dev-usefull Python package however.
So two different things:
1. Actually
https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
says that packages do now require it. I believe this started in Fedora
30-ish so EPEL-8/EPEL-9 packages will start requiring that.
2. We aren't talking about the OS including every dev-useful Python package. We are talking about a repository called EPEL including things which are in Fedora and trying to meet the needs for Enterprise clients which can be a mass of bailing wire of software going back to 20 years ago but also requiring the latest stuff. A good many of them can't just do a pypi install because they have ITIL or some other change control standard which says that the software must have been bundled in XYZ format, reviewed, etc. In the past EPEL was a good fit for python etc but it may not be with the modularization and fast moving python streams.
--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
