On Wed, Jul 8, 2015 at 4:18 AM, Ian Cordasco <graffatcolmin...@gmail.com>
wrote:
> On Tue, Jul 7, 2015 at 2:11 PM, Willy Wu <w...@dropbox.com> wrote:
> > So our flake8 might be a simpler case, where our lint tool invokes
> flake8 on
> > every file in the diff individually rather than a bunch of files at once.
> > Am I right to guess that if you do "flake8 .", then flake8 picks a single
> > per-project config file to apply across all files?
>
> Like I said, we do not change how flake8 behaves whether its running
> against a lot of files or whether it's running against a single file.
>
> When running flake8, it looks in the current working directory for a
> config file to apply to all files that it then discovers.
>
> >> > I think the source of our confusion is that we use py.test as our unit
> >> > test
> >> > runner, and they only consider setup.cfg a match if it contains a
> >> > [pytest]
> >> > section, so there's kind of a tension between how you guys and pytest
> >> > are
> >> > resolving configs.
> >>
> >> Except it's much more in line with how tox resolves configs. We can
> >> find points and counter-points but saying X should behave like Y is
> >> not a discussion worth having unless Y is a canonical implementation
> >> of something (and there really is no canon in this kind of
> >> configuration discovery/selection for Python tooling that looks in
> >> several places).
> >>
> >> > Let me know what else you need?
> >>
> >> Which setup.cfg has the Flake8 config? Is it
> >>
> >> - {repo_root}/setup.cfg
> >> - {repo_root}/{subservice_x}/setup.cfg
> >> - Something else?
> >
> >
> > {repo_root}/setup.cfg is originally the file w/ flake8 configs, and it's
> > where we were hoping to consolidate toward.
>
> And you're saying that doesn't work right now? I'm confused. That
> should Just Work⢠already. What won't work is shoving the config into
> the setup.cfg files in the subservices.
>
I made a gist with working shell code, it'll be easier for everyone if I
gave an example. :) It looks like the behavior for "flake8 ." vs "flake8
{path}" is different, which is probably why we're both kinda confused.
https://gist.github.com/willywu/f18211d1977a7189402b
Notice that if the root's setup.cfg is the only file w/ flake8 configs,
then `flake8 subproject1/src/myfile.py` doesn't use the root configs and
gives an error. But when I put the flake8 configs inside
of subproject1/setup.cfg, then we get the behavior that I was hoping for.
But with that said, I think a totally viable workaround is to run `flake8
subproject1/src/myfile.py --config=setup.cfg` which also does the behavior
that I'm hoping for.
Soo...seems to be that if you invoke flake8 with a path to a file, flake8
will stop at the first discovered setup.cfg (my original issue). But
that's atleast how pep8/tox works, even if it's not how py.test works. You
guys should update the docs on
http://flake8.readthedocs.org/en/latest/config.html to mention the --config
param! Because why would someone run `flake8 --help` instead of reading
the web docs...
>> Also, are each of the subservices actually their own packages or are
> >> you simply using setup.cfg to hold config for tooling? If they are
> >> separate packages there are different practices that could be followed
> >> (separate repositories, etc.) but, again, that's not my place.
> >
> > Each of the subservices is a separate service that gets deployed to its
> own
> > cluster in prod. We actually used to do separate repos for separate
> > services, but lately we wanted to do away with the overhead of lots of
> > little repos so we've been merging repos. This issue with multiple
> > setup.cfgs is the fallout of the repo merging. :)
> >
> >>
> >> If your CI is so inflexible that you have to run flake8 from
> >> repo_root, is it also so inflexible that you can't provide a path to
> >> the setup.cfg?
> >>
> >> Also, do the flake8 settings in each sub-service differ? If not, why
> >> can't they all be kept in the single setup.cfg in repo_root? I would
> >> imagine you'd want to enforce quality over an entire repository, not
> >> selectively over subparts of it. Other large projects have
> >> per-repository configs, not per-subproject configs. Wikimedia,
> >> OpenStack, and a few others all do it per project. Some have
> >> sub-packages that are in the repository and released from there, but
> >> they all observe the same flake8 settings.
> >
> > The flake8 settings in the subservices generally don't differ, which is
> why
> > we were hoping to consolidate their declarations everywhere. It's just
> that
> > the various subservices are overriding service-specific settings to
> > different values in their respective setup.cfgs.
>
> So if you can put all of them into a config file in repo_root, this
> should work. Did you try it and did it not work? (That config file can
> be setup.cfg, tox.ini, or .flake8).
>
> > Did you mention that flake8 can support a --config parameter that
> overrides
> > per-project config discovery? Since one source of the issue is that
> > multiple different projects are all using the same setup.cfg file, a
> > reasonable workaround might be to invoke flake8 with
> > --config={repo_root}/flake8.cfg which would ideally have the [flake8]
> > section that we're looking for.
>
> I forget exactly how pep8 applies the settings when you use --config,
> but yes that is an option you have.
>
> >> That said, I wonder if we stop searching for a config file when we've
> >> found one of {setup.cfg, tox.ini, .flake8} even if it doesn't have a
> >> flake8 section. That seems like a bug in pep8's config file discovery
> >> and parsing. That still wouldn't help you though. =/
> >
> > Yeah, that's exactly the problem - that we stop searching, even if the
> > discovered file doesn't have a flake8 section.
>
> I'm specifically talking about it being a bug if you have both
> setup.cfg and tox.ini and one has a [flake8] section while the other
> doesn't. If it finds/searches the one that doesn't first and then
> quits, that's a bug.
>
_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality
