On Sun, 16 Jan 2022 at 07:23, Miro Hrončok <mhroncok(a)redhat.com> 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