After thinking this over more, I agree we should continue to use flake8.
The situation I experienced is not typical when all of the code was
pre-black formatted so I think we're good. Even if you have to fix it
manually the second auto-commit black run will work correctly so I think
that will be ok
To kind of summarize your problem, at one point[0] you had this code:
from pulp_smash.api import _P3_TASK_END_STATES as P3_TASK_END_STATES #
noqa: F401
Then you ran black with a line length of 79 so black tried to make a best
guess as to where the comment should go:
from pulp_smash.api i
Black has at least 1 issue open where code it produces isn't compatible
with flake8 https://github.com/python/black/issues/195. I recently ran
into this with a contribution to pulp-smash.
I believe if we adopt black as the auto-formatter we shouldn't edit it
manually afterwards. For this reason I
I agree. I've opened a Pulp task for us to consider adding it to
plugin_template:
https://pulp.plan.io/issues/5073
David
On Wed, Jul 3, 2019 at 9:14 AM Bruno Rocha wrote:
>
> I guess, one could add a convenience / maintain script to run something
>> like 'make black'. Over time more (source)
> I guess, one could add a convenience / maintain script to run something
> like 'make black'. Over time more (source) maintenance task may come up.
that is exaclty where pre-commit is useful, it can run
black/flake8/whatever by a commit hook, and/or on demand using `pre-commit
run` command.
On
I guess, one could add a convenience / maintain script to run something
like 'make black'. Over time more (source) maintenance task may come up.
On Wed, 3 Jul 2019 09:26:26 -0300
Bruno Rocha wrote:
> There is the possibility to keep only flake8 and it will also run
> Black checks with https://py
There is the possibility to keep only flake8 and it will also run Black
checks with https://pypi.org/project/flake8-black/ plugin.
Then it is dev responsability to format the code in Black style or to use a
pre-commit if want.
On Wed, Jul 3, 2019 at 8:50 AM Ina Panova wrote:
> Seems like there
Seems like there are usecases where flake8 might be handy. Let's keep it
for now.
We can always drop it later, after people get more used to black.
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path an
Flake8 is a wrapper for pycodestyle, pyflakes, and mccabe. We probably
could just use the last two without pycodestyle. That said I lean toward
just keeping flake8 I suppose. It makes some of the configuration stuff
easy.
David
On Thu, Jun 27, 2019 at 3:12 PM Bruno Rocha wrote:
> If you set pr
If you set pre-commit hooks it is possible to have flake-8 to be executed
automatically after black format.
example:
https://github.com/rochacbruno/dynaconf/blob/master/.pre-commit-config.yaml#L31
Bruno Rocha
Senior Quality Engineer - Cloud Management QE - Pulp Project
*irc*: rochacbruno
*soci
On Thu, Jun 27, 2019 at 07:58:38AM -0400, David Davis wrote:
>Follow up question to adding support for black: should we drop flake8?
>We shouldn't need it anymore since black is pep8 compliant but I'm
>happy to keep it around at least temporarily if people prefer?
Please do not drop it
On Thu, Jun 27, 2019 at 8:03 AM Neal Gompa wrote:
> On Thu, Jun 27, 2019 at 7:59 AM David Davis wrote:
>
>> Follow up question to adding support for black: should we drop flake8? We
>> shouldn't need it anymore since black is pep8 compliant but I'm happy to
>> keep it around at least temporarily
On Thu, Jun 27, 2019 at 7:59 AM David Davis wrote:
> Follow up question to adding support for black: should we drop flake8? We
> shouldn't need it anymore since black is pep8 compliant but I'm happy to
> keep it around at least temporarily if people prefer?
>
Drop it. It's redundant and annoying
Follow up question to adding support for black: should we drop flake8? We
shouldn't need it anymore since black is pep8 compliant but I'm happy to
keep it around at least temporarily if people prefer?
David
On Mon, Jun 24, 2019 at 5:54 PM David Davis wrote:
> Per our PUP voting guidelines, PUP
Per our PUP voting guidelines, PUP-8 has passed and been merged. I filed
the required issues in an epic[0].
Thank you to everyone that voted and participated in the discussion.
[0] https://pulp.plan.io/issues/5019
David
On Mon, Jun 24, 2019 at 11:28 AM Ina Panova wrote:
> -0. Fully agree wit
-0. Fully agree with Tanya's 3rd point of observation.
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Wed, Jun 19, 2019 at 5:22 PM Austin Macdonald
wrote:
> +1. I like the
+1. I like the consistency but it's easy to overwhelm new contributors with
minor style comments, even if they are "standard".
On Tue, Jun 18, 2019 at 5:55 PM David Davis wrote:
> Agreed. You don't have to use black to autoformat your code if you don't
> want to. You could run black to check you
Agreed. You don't have to use black to autoformat your code if you don't
want to. You could run black to check your code locally (with --check) or
wait to have travis do it for you like we do now with flake8. It's up to
you whether to autoformat your code or not.
Also, just FYI: I updated PUP-8 to
+1
Agree with some of the concerns listed above and in PUP-8. The focus on the
logical changes to code and the behavior/quality of the software over code
style seems like the correct call.
>From a QE perspective, for how and where to rollout, I would also consider
making changes first to test cod
I would argue that nothing stops you having pep8 down to muscle memory, it
just means the autoformatter has less output :)
Matt P.
On Tue, Jun 18, 2019 at 9:32 AM Dana Walker wrote:
> -0
>
> If we want devs free "from having to worry about formatting their code
> while developing", I think that
-0
If we want devs free "from having to worry about formatting their code
while developing", I think that's doing both them and the community a
disservice in the long run. I at least learn through doing, repetitively,
and think it would be more beneficial to have pep8 down to muscle memory in
tim
+1 to adopt black code style.
Reasons already listed.
On Tue, Jun 18, 2019 at 4:34 AM Tatiana Tereshchenko
wrote:
> -0
>
> I'm usually all for consistency, and having standard style sounds good in
> theory.
>
> 1. What worries me is that there is basically no way back, we can't just
> try i
-0
I'm usually all for consistency, and having standard style sounds good in
theory.
1. What worries me is that there is basically no way back, we can't just
try it out.
Maybe waiting a bit to see if black has more adoption in the Python
community and goes GA is not a bad idea.
2. Is now the poi
+0
On Mon, Jun 17, 2019 at 1:15 PM Brian Bouterse wrote:
> +1 to adopting this. Thank you @daviddavis for writing
>
> On Mon, Jun 10, 2019 at 1:58 PM David Davis wrote:
>
>> I opened PUP-8 that proposes adopting black and pydocstyle[0] along with
>> a PR against pulpcore to demonstrate how it w
+1 to adopting this. Thank you @daviddavis for writing
On Mon, Jun 10, 2019 at 1:58 PM David Davis wrote:
> I opened PUP-8 that proposes adopting black and pydocstyle[0] along with a
> PR against pulpcore to demonstrate how it would change pulpcore's code.
> Please review and respond with votes[
I opened PUP-8 that proposes adopting black and pydocstyle[0] along with a
PR against pulpcore to demonstrate how it would change pulpcore's code.
Please review and respond with votes[2]. The deadline will be June 22, 2019.
[0] https://github.com/pulp/pups/pull/17
[1] https://github.com/pulp/pulpc
On Tue, Jun 04, 2019 at 08:25:47AM -0400, David Davis wrote:
>I wanted to get feedback from the Pulp community on using black[0] to
>auto-format our Pulp 3 code. I have some mixed feelings about it as I
>see some potential benefits of using it but also some downsides as
>well.
+1 f
On Tue, 4 Jun 2019 13:40:38 -0400
Austin Macdonald wrote:
> I think there are enough big projects that use black to consider it
> ready. (PyPI for another example, and we also know it is being
> actively developed).
'Being actively developed' is not necessarily a good thing in this
context. If th
On Tue, Jun 4, 2019 at 1:46 PM David Davis wrote:
> @asmacdo in my original email there is a link to a pulp_rpm PR. Here it is
> again:
>
> https://github.com/pulp/pulp_rpm/pull/1355
>
> I'd be happy to open PRs against pulpcore and/or pulp_file as well.
>
> David
>
Ah, sorry I missed that. I'd
Austin worded it better than me :) That's what I was trying to get at. My
bad.
Also I was going to suggest a POC branch to get some more real world data
on the impact, but he kind of beat me to it as well. So much for hitting
send before re-reading my thoughts.
On Tue, Jun 4, 2019 at 1:44 PM Aus
@asmacdo in my original email there is a link to a pulp_rpm PR. Here it is
again:
https://github.com/pulp/pulp_rpm/pull/1355
I'd be happy to open PRs against pulpcore and/or pulp_file as well.
David
On Tue, Jun 4, 2019 at 1:41 PM Austin Macdonald wrote:
> I think there are enough big project
On Tue, Jun 4, 2019 at 1:40 PM Matt Pusateri wrote:
>
>
>
> On Tue, Jun 4, 2019 at 1:15 PM Mike DePaulo wrote:
>
>> On Tue, Jun 4, 2019 at 12:09 PM Robin Chan wrote:
>>
>>> Mike, clarification question below...
>>>
>>> On Tue, Jun 4, 2019 at 11:45 AM Mike DePaulo
>>> wrote:
>>>
On Tue, Ju
I think there are enough big projects that use black to consider it ready.
(PyPI for another example, and we also know it is being actively
developed).
IMO the way to make this choice is to determine whether the style it
uses/enforces works well for the project. There might be legitimate reasons
t
On Tue, Jun 4, 2019 at 1:15 PM Mike DePaulo wrote:
> On Tue, Jun 4, 2019 at 12:09 PM Robin Chan wrote:
>
>> Mike, clarification question below...
>>
>> On Tue, Jun 4, 2019 at 11:45 AM Mike DePaulo
>> wrote:
>>
>>> On Tue, Jun 4, 2019 at 9:14 AM Brian Herring
>>> wrote:
>>>
> Moreover, usi
On Tue, Jun 4, 2019 at 12:09 PM Robin Chan wrote:
> Mike, clarification question below...
>
> On Tue, Jun 4, 2019 at 11:45 AM Mike DePaulo
> wrote:
>
>> On Tue, Jun 4, 2019 at 9:14 AM Brian Herring wrote:
>>
>>> > Moreover, using black would effectively take style comments/noise out
>>> of PR r
Mike, clarification question below...
On Tue, Jun 4, 2019 at 11:45 AM Mike DePaulo wrote:
> On Tue, Jun 4, 2019 at 9:14 AM Brian Herring wrote:
>
>> > Moreover, using black would effectively take style comments/noise out
>> of PR reviews and we could just focus on logic.
>>
>> QE looked into th
On Tue, Jun 4, 2019 at 9:14 AM Brian Herring wrote:
> > Moreover, using black would effectively take style comments/noise out of
> PR reviews and we could just focus on logic.
>
> QE looked into this for a while, and I think it is a WONDERFUL addition...
> especially for the reasons stated above.
QE adopted black for Pulp-Smash and it is helping us to avoid the extra
work on coding style.
I also adopted black + pre-commit in all my open-souce repositories like
"Dynaconf" and it is working very well.
+1 for Black
Bruno Rocha
Senior Quality Engineer - Cloud Management QE - Pulp Project
*i
On Tue, Jun 4, 2019 at 8:45 AM Dana Walker wrote:
> I think it's important to note that Django voted to adopt it once it is
> out of beta and stable, which is not yet the case.
>
This is true although it seems that they are close to being stable.
Although they were supposed to go stable right af
On Tue, Jun 4, 2019 at 8:27 AM David Davis wrote:
> I wanted to get feedback from the Pulp community on using black[0] to
> auto-format our Pulp 3 code. I have some mixed feelings about it as I see
> some potential benefits of using it but also some downsides as well.
>
> For potential upsides, I
We have been using black code style for a while now together with
pre-commit hooks[0] and it has been great.
There are some good reasons to adopt black - even in beta:
1 - Standard - This makes life easier to anyone that wants to contribute to
a certain project.
Same standard across all code
> Moreover, using black would effectively take style comments/noise out of
PR reviews and we could just focus on logic.
QE looked into this for a while, and I think it is a WONDERFUL addition...
especially for the reasons stated above.
Some tweaking would be needed, but it is one less item to wor
I think it's important to note that Django voted to adopt it once it is out
of beta and stable, which is not yet the case.
I was surprised they went for it instead of autopep8 or other options given
the reason the pulp_python team closed the PR for black was that it was not
pep8 compliant. Maybe
I wanted to get feedback from the Pulp community on using black[0] to
auto-format our Pulp 3 code. I have some mixed feelings about it as I see
some potential benefits of using it but also some downsides as well.
For potential upsides, I think it would be nice if all our projects in Pulp
conformed
44 matches
Mail list logo
