1:49 a.m.
Back to everyone's favorite topic - coding style and enforcement of
that style.
I'm not picking on Josef here - I'm sure I've submitted code recently
with lint errors, this was just the review I was looking at which
triggered the idea:
https://phab.qadevel.cloud.fedoraproject.org/D389
Since the last discussion about coding style ended in a long discussion
about PEP8, the bits we may not like about the standard and the
exceptions that we'd want, I'm proposing that we use strict PEP8 with
almost no exceptions. I'm not saying that that PEP8 is perfect or
that there aren't parts of it I would like to tweak but
- it's a well known standard, easy for non-regular contributors to
understand and use
- style checking tools tend to use PEP8 out of the box
- if we don't allow exceptions, there will be less time spent on
discussing details instead of being productive :)
To be more specific, I am proposing the following:
- all QA devel projects be have flake8 as the linter in arc config
- no code be accepted with lint errors unless there is absolutely no
other way to get around it
- until we get our entire codebase PEP8 compliant, "if you touch a
file, fix the lint errors even if those errors are not part of what
you're changing"
Any strong objections to starting this? Any strong objections should
have an alternative proposal and a justification why that proposal is
worth deviating from a well known and established standard.
Tim
4:16 a.m.
----- Original Message -----
From: "Tim Flink" <tflink(a)redhat.com>
To: qa-devel(a)lists.fedoraproject.org
Sent: Friday, June 12, 2015 8:49:53 AM
Subject: Coding Style
Back to everyone's favorite topic - coding style and enforcement of
that style.
I'm not picking on Josef here - I'm sure I've submitted code recently
with lint errors, this was just the review I was looking at which
triggered the idea:
https://phab.qadevel.cloud.fedoraproject.org/D389
Since the last discussion about coding style ended in a long discussion
about PEP8, the bits we may not like about the standard and the
exceptions that we'd want, I'm proposing that we use strict PEP8 with
almost no exceptions. I'm not saying that that PEP8 is perfect or
that there aren't parts of it I would like to tweak but
- it's a well known standard, easy for non-regular contributors to
understand and use
- style checking tools tend to use PEP8 out of the box
- if we don't allow exceptions, there will be less time spent on
discussing details instead of being productive :)
To be more specific, I am proposing the following:
- all QA devel projects be have flake8 as the linter in arc config
- no code be accepted with lint errors unless there is absolutely no
other way to get around it
- until we get our entire codebase PEP8 compliant, "if you touch a
file, fix the lint errors even if those errors are not part of what
you're changing"
Any strong objections to starting this? Any strong objections should
have an alternative proposal and a justification why that proposal is
worth deviating from a well known and established standard.
By saying we should use strict PEP8, does that mean you want to get
rid of the linter settings we have in .arclint or leave it there?
Other than that, I have no objections. I am all for being strict and
consistent and avoiding discussing details at the expense of productivity.
Thanks,
Martin
8:21 a.m.
> Back to everyone's favorite topic - coding style and
enforcement of
> that style.
And I thought we were doing so great by leaving it behind...
>
> I'm not picking on Josef here - I'm sure I've submitted code recently
> with lint errors, this was just the review I was looking at which
> triggered the idea:
>
> https://phab.qadevel.cloud.fedoraproject.org/D389
As I already mentioned in the review, the way how Phab displays lint errors is a problem
in this particular case - the diff is hard to read. That is something I'd like to
avoid in the future.
>
> Since the last discussion about coding style ended in a long discussion
> about PEP8, the bits we may not like about the standard and the
> exceptions that we'd want, I'm proposing that we use strict PEP8 with
> almost no exceptions.
The big hammer solution! ;-)
> I'm not saying that that PEP8 is perfect or
> that there aren't parts of it I would like to tweak but
> - it's a well known standard, easy for non-regular contributors to
> understand and use
> - style checking tools tend to use PEP8 out of the box
> - if we don't allow exceptions, there will be less time spent on
> discussing details instead of being productive :)
The opposite is true for me. My experience with lint warnings in Phab (before we loosened
the rules) is that I spent a considerable time rewriting and reformatting the code until
the damn linter finally shut up (I'd probably need stronger words to demonstrate my
temper at that time:)). Also it made the code slightly less readable sometimes (a personal
view), which annoyed me. I lose no productivity on seeing an occasional lint warning in
diff review (D389 is a slight exception in a very long time).
That being said, I try to minimize the number of lint warnings with my every patch, unless
I consider that specific rule particularly braindead.
>
> To be more specific, I am proposing the following:
> - all QA devel projects be have flake8 as the linter in arc config
> - no code be accepted with lint errors unless there is absolutely no
> other way to get around it
> - until we get our entire codebase PEP8 compliant, "if you touch a
> file, fix the lint errors even if those errors are not part of what
> you're changing"
>
> Any strong objections to starting this? Any strong objections should
> have an alternative proposal and a justification why that proposal is
> worth deviating from a well known and established standard.
>
I have an alternative proposal:
1. The Phab diff should not contain too many lint warnings without a good enough reason,
in order to keep it readable.
2. If it does, ask the author to fix it.
3. If the author is reluctant to change his coding style, and you have no strong objection
to it per se (you just want the Phab diff to be readable), let's disable the
particular lint check.
In this case it would involve asking Josef to stop putting spaces between parameter
keyvals, or disabling "unexpected spaces around keyword / parameter equals"
check. It could also involve disabling "continuation line over-indented for hanging
indent" check, because that's another very common warning we just ignore.
The only problem will be when two people have strong and conflicting opinions on how to
code should look. Is this the case? If not, then if we implement the solution describe
above, I believe we're not going to be discussing code style in another year or two,
judging by the past.
By saying we should use strict PEP8, does that mean you want to get
rid of the linter settings we have in .arclint or leave it there?
Strict PEP8 would mean all the configured exceptions would be purged.
Oh boy, this will be a long discussion once again.
9:33 a.m.
On Fri, 12 Jun 2015 09:21:38 -0400 (EDT)
Kamil Paral <kparal(a)redhat.com> wrote:
> > Back to everyone's favorite topic - coding style and
enforcement
> > of that style.
And I thought we were doing so great by leaving it behind...
> >
> > I'm not picking on Josef here - I'm sure I've submitted code
> > recently with lint errors, this was just the review I was looking
> > at which triggered the idea:
> >
> > https://phab.qadevel.cloud.fedoraproject.org/D389
As I already mentioned in the review, the way how Phab displays lint
errors is a problem in this particular case - the diff is hard to
read. That is something I'd like to avoid in the future.
Getting rid of most lint errors/warnings/advice would be one way of
doing that :)
> >
> > Since the last discussion about coding style ended in a long
> > discussion about PEP8, the bits we may not like about the
> > standard and the exceptions that we'd want, I'm proposing that we
> > use strict PEP8 with almost no exceptions.
The big hammer solution! ;-)
I prefer to think of it as the simple hammer solution ... that
happens to be big :)
> > I'm not saying that that PEP8 is perfect or
> > that there aren't parts of it I would like to tweak but
> > - it's a well known standard, easy for non-regular contributors
> > to understand and use
> > - style checking tools tend to use PEP8 out of the box
> > - if we don't allow exceptions, there will be less time spent on
> > discussing details instead of being productive :)
The opposite is true for me. My experience with lint warnings in Phab
(before we loosened the rules) is that I spent a considerable time
rewriting and reformatting the code until the damn linter finally
shut up (I'd probably need stronger words to demonstrate my temper at
that time:)). Also it made the code slightly less readable sometimes
(a personal view), which annoyed me. I lose no productivity on seeing
an occasional lint warning in diff review (D389 is a slight exception
in a very long time).
That being said, I try to minimize the number of lint warnings with
my every patch, unless I consider that specific rule particularly
braindead.
Running flake8 on code before using arc is one option - using an
editor/ide that has flake8/pep8 checking enabled is another way to
make the change less frustrating.
Again, I'm not saying that I'm thrilled with all the rules in PEP8 -
several of them are going to require me to break some of my habits but
I do think that this will save time and effort in the long run.
> >
> > To be more specific, I am proposing the following:
> > - all QA devel projects be have flake8 as the linter in arc
> > config
> > - no code be accepted with lint errors unless there is
> > absolutely no other way to get around it
> > - until we get our entire codebase PEP8 compliant, "if you touch
> > a file, fix the lint errors even if those errors are not part of
> > what you're changing"
> >
> > Any strong objections to starting this? Any strong objections
> > should have an alternative proposal and a justification why that
> > proposal is worth deviating from a well known and established
> > standard.
> >
I have an alternative proposal:
1. The Phab diff should not contain too many lint warnings without a
good enough reason, in order to keep it readable. 2. If it does, ask
the author to fix it. 3. If the author is reluctant to change his
coding style, and you have no strong objection to it per se (you just
want the Phab diff to be readable), let's disable the particular lint
check.
In this case it would involve asking Josef to stop putting spaces
between parameter keyvals, or disabling "unexpected spaces around
keyword / parameter equals" check. It could also involve disabling
"continuation line over-indented for hanging indent" check, because
that's another very common warning we just ignore.
I'm pretty much at a harder stance than that - unless there is a reason
that the code cannot be refactored to pass lint, it should have 0 lint
errors, warnings or advice. Discussing why a particular message is "ok
this time because ..." costs time and energy that would be avoided with
simpler rules. Code style enforcement is there to make sure that code
is consistently styled - if there are (semi) frequent exceptions to the
rules, what's the point of checking style in the first place?
The only problem will be when two people have strong and conflicting
opinions on how to code should look. Is this the case? If not, then
if we implement the solution describe above, I believe we're not
going to be discussing code style in another year or two, judging by
the past.
Which is exactly what I want to avoid by saying "no exceptions unless
unavoidable". I suspect that we all have habits which go against PEP8
and it'll take some relearning of habits but it's not like PEP8 is some
obscure standard which nobody else uses, this won't be the last time
that patches would be required to adhere to that standard.
> By saying we should use strict PEP8, does that mean you want to
get
> rid of the linter settings we have in .arclint or leave it there?
Strict PEP8 would mean all the configured exceptions would be purged.
Most, if not all, yes. If we take the route of not allowing exceptions,
I don't think there's a reason to keep the config that's changing
errors to "advice" or "warning" - reviews with advice or warnings
wouldn't be more acceptable than errors and I don't see the difference.
Oh boy, this will be a long discussion once again.
Which I really want to avoid and why I'm proposing strict PEP8 - fewer
variables and less time spent figuring out what everyone's "issues"
with the standard are.
Tim
10:47 p.m.
On 06/13/2015 12:33 AM, Tim Flink wrote:
On Fri, 12 Jun 2015 09:21:38 -0400 (EDT)
Kamil Paral <kparal(a)redhat.com> wrote:
>>> Back to everyone's favorite topic - coding style and enforcement
>>> of that style.
>
> And I thought we were doing so great by leaving it behind...
>
>>>
>>> I'm not picking on Josef here - I'm sure I've submitted code
>>> recently with lint errors, this was just the review I was looking
>>> at which triggered the idea:
>>>
>>> https://phab.qadevel.cloud.fedoraproject.org/D389
>
> As I already mentioned in the review, the way how Phab displays lint
> errors is a problem in this particular case - the diff is hard to
> read. That is something I'd like to avoid in the future.
Getting rid of most lint errors/warnings/advice would be one way of
doing that :)
Folks can also configure their local clone to run the flake8 checks
before allowing a commit: https://flake8.readthedocs.org/en/latest/vcs.html
Code contributions to open source projects are "free as in puppy" rather
than "free as in beer", and core contributor time is almost always the
limiting factor on development progress, so it's reasonable to impose
certain minimal expectations on potential contributors.
Cheers,
Nick.
--
Nick Coghlan
Red Hat PnT Operations
DevOps Enablement, Brisbane
Software Development Workflow Designer & Process Architect
5:19 a.m.
> > I'm not picking on Josef here - I'm sure I've
submitted code recently
> > with lint errors, this was just the review I was looking at which
> > triggered the idea:
> >
> > https://phab.qadevel.cloud.fedoraproject.org/D389
No worries, I'm not taking it personaly. As I commented in the D389 - the "not
compliant" parts of the code were mostly in the spirit ofthe rest of the code in the
respective files (thus actually honoring the PEP8
-https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
). Not saying that it is the best though.
> > exceptions that we'd want, I'm proposing that we
use strict PEP8 with
> > almost no exceptions.
For me, strict PEP8 is next-to-unusable, and almost always leads to code like this:
+ result = self.resultsdb.create_result(job_id=job_data['id'],
+ testcase_name=checkname,
+ outcome=detail.outcome,
+ summary=detail.summary
+ or None,
+ log_url=result_log_url,
+ item=detail.item,
+ type=detail.report_type,
+ **detail.keyvals
+ )
Hard to read, and heavily concentrated to the right edge of the 80-char mark.
...
In this case it would involve asking Josef to stop putting spaces between
parameter keyvals
I actually did stop doing that quite some time ago :)
First of all I'd suggest to move our codebase to strict PEP8 (or
as-strict-as-possible), so we can have see how our code looks like, when PEP8 compliant.
For starters, we could just plain use autopep8 - https://pypi.python.org/pypi/autopep8/
How about that?
J.
11:29 a.m.
On Mon, 2015-06-15 at 06:19 -0400, Josef Skladanka wrote:
>
> > > I'm not picking on Josef here - I'm sure I've submitted code
> > > recently
> > > with lint errors, this was just the review I was looking at
> > > which
> > > triggered the idea:
> > >
> > > https://phab.qadevel.cloud.fedoraproject.org/D389
No worries, I'm not taking it personaly. As I commented in the D389 -
the "not compliant" parts of the code were mostly in the spirit ofthe
rest of the code in the respective files (thus actually honoring the
PEP8 -https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency
-is-the-hobgoblin-of-little-minds ). Not saying that it is the best
though.
> > > exceptions that we'd want, I'm proposing that we use strict
> > > PEP8 with
> > > almost no exceptions.
For me, strict PEP8 is next-to-unusable, and almost always leads to
code like this:
+ result = self.resultsdb.create_result(job_id=job_data['id'],
+ testcase_name=checkname,
+ outcome=detail.outcome,
+ summary=detail.summary
+ or None,
+ log_url=result_log_url,
+ item=detail.item,
+ type=detail.report_type,
+ **detail.keyvals
+ )
As I read it (of course IMBW), PEP-8 also allows for:
result = self.resultsdb.create_result(
job_id=job_data['id'], testcase_name=checkname,
outcome=detail.outcome, summary=detail.summary or None,
log_url=result_log_url, item=detail.item,
type=detail.report_type, **detail.keyvals)
unless the next line would be indented, in which case you add one extra
level of indentation here. I use that style quite a bit in my stuff.
I do think it makes sense to be a bit less strict than PEP-8 for line
lengths especially when we have existing code that has been written to
longer lengths, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:15 p.m.
First of all I'd suggest to move our codebase to strict PEP8 (or
as-strict-as-possible), so we can have see how our code looks like, when
PEP8 compliant.
For starters, we could just plain use autopep8 -
https://pypi.python.org/pypi/autopep8/
How about that?
For the record, Josef put up the diff here:
https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/
As the most vocal naysayer during the IRC meeting, I have went through all of those
changes (and I have read PEP8 again), and I have to say the changes are not that bad. I
have feared that the code would look similarly to what Josef quoted in the email, but PEP8
is actually saner than I expected and allows much better stylistic formatting.
Which in fact touches one of the concerns I have, that it's hard to realize how to
write the code pretty and still comply to PEP8, but it's easy to realize how to write
the code ugly and comply. At least that's my experience.
I still have a few pet peeves about PEP8, for example check.py:189-192 or
config_defaults.py:63. I think human being can use whitespace to make code much more
readable (the code is in a monospace font for a reason), and PEP8's "I know
better" approach of enforced conformity quite bothers me. But I understand that can
be highly subjective, and for some people consistency is above readability, for me it is
the other way around.
That said, if everyone else happily supports this idea, I don't object against a trial
run in which we drop all custom configuration from .arclint and enable pep8 checking. We
will see how it works out. I don't think it will boost our productivity, I think it
will just move the "wasted" time from reviews (let's admit it, almost none
in the past months) to the patch preparation process and multiply it, but maybe I'm
wrong.
PS: Speaking of line length, PEP8 actually allows going up to 100 chars [1], and most of
our existing codebase meets that, so I don't see that as much of a problem. The
comments and docstrings still need to be wrapped at 72 chars, though, so I'm curious
to see if we start to enforce that.
[1] https://www.python.org/dev/peps/pep-0008/#maximum-line-length
9:08 a.m.
On Fri, 12 Jun 2015 05:16:57 -0400 (EDT)
Martin Krizek <mkrizek(a)redhat.com> wrote:
----- Original Message -----
> From: "Tim Flink" <tflink(a)redhat.com>
> To: qa-devel(a)lists.fedoraproject.org
> Sent: Friday, June 12, 2015 8:49:53 AM
> Subject: Coding Style
>
> Back to everyone's favorite topic - coding style and enforcement of
> that style.
>
> I'm not picking on Josef here - I'm sure I've submitted code
> recently with lint errors, this was just the review I was looking
> at which triggered the idea:
>
> https://phab.qadevel.cloud.fedoraproject.org/D389
>
> Since the last discussion about coding style ended in a long
> discussion about PEP8, the bits we may not like about the standard
> and the exceptions that we'd want, I'm proposing that we use strict
> PEP8 with almost no exceptions. I'm not saying that that PEP8 is
> perfect or that there aren't parts of it I would like to tweak but
> - it's a well known standard, easy for non-regular contributors to
> understand and use
> - style checking tools tend to use PEP8 out of the box
> - if we don't allow exceptions, there will be less time spent on
> discussing details instead of being productive :)
>
> To be more specific, I am proposing the following:
> - all QA devel projects be have flake8 as the linter in arc config
> - no code be accepted with lint errors unless there is absolutely
> no other way to get around it
> - until we get our entire codebase PEP8 compliant, "if you touch a
> file, fix the lint errors even if those errors are not part of
> what you're changing"
>
> Any strong objections to starting this? Any strong objections should
> have an alternative proposal and a justification why that proposal
> is worth deviating from a well known and established standard.
>
By saying we should use strict PEP8, does that mean you want to get
rid of the linter settings we have in .arclint or leave it there?
Keep the linter and get rid of most, if not all of the exceptions we
have in there was my thought. At a bare minimum, start requiring that
pretty much all lint issues be fixed prior to accepting a diff
Tim
12:25 p.m.
On Fri, 12 Jun 2015 00:49:53 -0600
Tim Flink <tflink(a)redhat.com> wrote:
To be more specific, I am proposing the following:
- all QA devel projects be have flake8 as the linter in arc config
- no code be accepted with lint errors unless there is absolutely no
other way to get around it
- until we get our entire codebase PEP8 compliant, "if you touch a
file, fix the lint errors even if those errors are not part of what
you're changing"
Any strong objections to starting this? Any strong objections should
have an alternative proposal and a justification why that proposal is
worth deviating from a well known and established standard.
After the meeting earlier today, I wanted to make a slightly different
proposal.
- if flake8 config in arcanist can be so configured, set max line
width to 120 instead of 79
- default to "no" on lint exceptions - the idea is to avoid spending
time debating whether an exception is worth it or not.
- until we get the codebase compliant "if you touch a file, fix the
lint errors even if those errors are not part of what you're
changing"
With the current split of develop and disposable-develop, I'd like to
avoid the merge issues that would come about from a big change to
develop that may conflict with changes we've already made in
disposable-develop.
Thoughts?
Tim
5:25 a.m.
After the meeting earlier today, I wanted to make a slightly
different
proposal.
- if flake8 config in arcanist can be so configured, set max line
width to 120 instead of 79
On my 1920px monitor, two windows with 100 columns fit perfectly next to each other (11px
font). Is there a strong desire to go over 100 cols? It would make file comparisons less
practical. And 100 (well, 99) is still PEP8-approved.
I have no problems exceeding that limit in certain specific cases. For example, because we
often bundle documentation with the source code, and we format it with rst, it might
happen that a large block of text is indented far right and it makes it very long. Or
there are some code samples which can be wrapped but it makes them hard to read. In such
cases I have no problem having these particular lines go to 120 (or even more, if needed).
But this would be very exceptional and almost never applied to regular code - no need to
worry about linter exceptions discussions, I think.
PS: It seems that flake8 can't be configured in arcanist at the moment. The patch was
written [1] but abandoned and never pushed [2]. It seems quite simple, though, so we could
finish that up, if desired. The other approach is to disable line length checking in
flake8 and use generic ArcanistTextLinter [3] for it, it's even mentioned in the docs
[4]. That should be less work.
[1] https://secure.phabricator.com/D10512
[2]
https://github.com/phacility/arcanist/blob/master/src/lint/linter/Arcanis...
[3]
https://github.com/phacility/arcanist/blob/master/src/lint/linter/Arcanis...
[4]
https://secure.phabricator.com/book/phabricator/article/arcanist_extendin...
- default to "no" on lint exceptions - the idea is to avoid spending
time debating whether an exception is worth it or not.
If I read this correctly as "we don't have a strict 0-exceptions policy, but they
should be very rare and if you propose one, you should have a very good reason to do
so", I think that's fine and we'll see how that works in the next months.
- until we get the codebase compliant "if you touch a file, fix the
lint errors even if those errors are not part of what you're
changing"
Even though this will make our files a bit consistent (modified parts looking a bit
different than unmodified parts), I don't mind much and I think that this approach is
fine for the moment. Especially before we find out if we're happy with the new
approach. It will also minimize the changes between develop and disposable-develop.
12:27 p.m.
On Tue, 16 Jun 2015 06:25:22 -0400 (EDT)
Kamil Paral <kparal(a)redhat.com> wrote:
> After the meeting earlier today, I wanted to make a slightly
> different proposal.
>
> - if flake8 config in arcanist can be so configured, set max line
> width to 120 instead of 79
On my 1920px monitor, two windows with 100 columns fit perfectly next
to each other (11px font). Is there a strong desire to go over 100
cols? It would make file comparisons less practical. And 100 (well,
99) is still PEP8-approved.
Yeah, 100 is fine by me. 120 was a somewhat arbitrary number that I
thought I remembered from previous conversations
I have no problems exceeding that limit in certain specific cases.
For example, because we often bundle documentation with the source
code, and we format it with rst, it might happen that a large block
of text is indented far right and it makes it very long. Or there are
some code samples which can be wrapped but it makes them hard to
read. In such cases I have no problem having these particular lines
go to 120 (or even more, if needed). But this would be very
exceptional and almost never applied to regular code - no need to
worry about linter exceptions discussions, I think.
PS: It seems that flake8 can't be configured in arcanist at the
moment. The patch was written [1] but abandoned and never pushed [2].
It seems quite simple, though, so we could finish that up, if
desired. The other approach is to disable line length checking in
flake8 and use generic ArcanistTextLinter [3] for it, it's even
mentioned in the docs [4]. That should be less work.
I think that we can work around this by putting config items in
setup.cfg or tox.ini like they talk about in that revision (and why the
author abandoned it, I think).
[1] https://secure.phabricator.com/D10512
[2]
https://github.com/phacility/arcanist/blob/master/src/lint/linter/Arcanis...
[3]
https://github.com/phacility/arcanist/blob/master/src/lint/linter/Arcanis...
[4]
https://secure.phabricator.com/book/phabricator/article/arcanist_extendin...
>
> - default to "no" on lint exceptions - the idea is to avoid
> spending time debating whether an exception is worth it or not.
If I read this correctly as "we don't have a strict 0-exceptions
policy, but they should be very rare and if you propose one, you
should have a very good reason to do so", I think that's fine and
we'll see how that works in the next months.
That's pretty much what I meant, yeah.
Setting rigid "absolutely no exceptions ever" rules are generally a bad
idea. Unavoidable at times but there are usually problems that come
along with them.
>
> - until we get the codebase compliant "if you touch a file, fix the
> lint errors even if those errors are not part of what you're
> changing"
Even though this will make our files a bit consistent (modified parts
looking a bit different than unmodified parts), I don't mind much and
I think that this approach is fine for the moment. Especially before
we find out if we're happy with the new approach. It will also
minimize the changes between develop and disposable-develop.
Yeah, let's see how well this works out. Hopefully we'll be able to
merge disposable-develop back into develop soon and we won't have 2
active-ish branches to keep up to date.
Tim
3:55 a.m.
> PS: It seems that flake8 can't be configured in arcanist at
the
> moment. The patch was written [1] but abandoned and never pushed [2].
> It seems quite simple, though, so we could finish that up, if
> desired. The other approach is to disable line length checking in
> flake8 and use generic ArcanistTextLinter [3] for it, it's even
> mentioned in the docs [4]. That should be less work.
I think that we can work around this by putting config items in
setup.cfg or tox.ini like they talk about in that revision (and why the
author abandoned it, I think).
You were right, it worked. The patch is here:
https://phab.qadevel.cloud.fedoraproject.org/D399
Will we try to live with it in libtaskotron for a while, or should I create similar
patches for all our projects right away?
5:03 a.m.
----- Original Message -----
From: "Kamil Paral" <kparal(a)redhat.com>
Will we try to live with it in libtaskotron for a while, or should I create
similar patches for all our projects right away?
I vote for doing it everywhere. I have already converted the ExecDB using autopep8
`autopep8 -r --max-line-length 99 --in-place -a -a ./` as there is next to none
change in git-blame's blaming there.
For the other projects (including libtaskotron, once we merge the disposable-clients
branch),
I suggest using fake author `git commit --author "Auto PEP8
<qa-devel(a)lists.fedoraproject.org>"`
for the autopep8 initial conversion's commit, so one can then easily dig-deeper with
git-blame,
if needed.
Thoughts?
3228
days inactive
3234
days old
qa-devel@lists.fedoraproject.org
13 comments
6 participants
participants (6)
-
Adam Williamson -
Josef Skladanka -
Kamil Paral -
Martin Krizek -
Nick Coghlan -
Tim Flink