Re: Don't lint in %check (Was: python-flake8 package not available in F30)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 11, 2019 at 11:00 AM Petr Viktorin <pviktori@xxxxxxxxxx> wrote:
>
> On 3/9/19 7:33 PM, Chris wrote:
> > Thank you both for your fast reply!
> >
> >  >  Why do you need to BuildRequire a linting tool? What are you trying
> > to achieve?
> >
> > I just use python-flake8 as an OCD way of having my build fail if i fail
> > pep8 :)  It's just used in conjunction of my unit tests.
>
> Running a linter is fine upstream, but I'll argue that you'll be much
> better off disabling it for the distro build.
>
> Newer versions of flake8 can cause your tests to suddenly fail. We've
> seen that happen relatively often -- style standards themselves evolve,
> and the way they're codified in automatic tools evolves.

If upstream takes <insert linter here> seriously, and the package
maintainer does too, then following our First principle I would argue
it's fine to get an FTBFS as a result of an <insert linter here>
update iff the package maintainer is willing to patch their package
and upstream the patch.

> Upstream, please do check code style or unused imports if that's your
> thing. But after you cut a release (on GitHub/PyPI), linting the code
> doesn't really bring any benefit. (Unlike running the test suite, of
> course.)

But a release should be definitive, a "linter" bug is like any other
bug, it can be patched downstream and fixed in the next release.

> Even if you're currently maintaining this both upstream and in Fedora,
> and have the energy to watch for & fix any failures, after some years
> you might want to pass the package on to someone else. Be nice to your
> successor. And be nice your potential Debian (et al.) maintainers by
> making your specfile show how to package for a distro :)

As package maintainers we are supposed to stay in touch with upstream
projects, so letting them know about changes in <insert linter here>
should be part of that relationship.

> (Note: AFAIK this is not official Fedora policy; please
> disagree/discuss/argue.)

Same for me, just my personal opinion full of ifs :)

Dridi
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux