provide a `flit lint` command

[Carreau]

That lint flit.ini files (for unknown field ?) and potentially report error in "classical" sprintf format which is easy to hook into editors.

Thoughts ?

[takluyver]

Are you thinking of the same checks that flit already does, or something more detailed? If editor integration is practical, that certainly sounds good. Though we're likely to end up changing to pyproject.toml files (#77), so let's not rush into doing something specific for flit.ini files.

[dholth]

If it winds up a dict, https://pypi.python.org/pypi/jsonschema (don't remember if this is the exact library I used) is very handy.

[takluyver]

It does, and we also use jsonschema in the notebook, so I have an example handy :-)

[Carreau]

Are you thinking of the same checks that flit already does, or something more detailed?

yes, roughly; mostly catching bad keys, I never remember between python_requires and requires_python and forgot s here and there.

I guess once we move to pyproject.toml the linter will still be useful as it will still catch bad keys.

[takluyver]

Actually, one downside of moving to pyproject.toml is that it makes linting trickier, because what it contains depends on what buildsystem you use. We could probably build a linter that skips it entirely if it doesn't have a tool.flit section. But a more advanced solution would be a linter that can ask different packaging tools to check their respective metadata.

[Carreau]

Well, I register multiple linters with my editor, which does blend all the linting results. So as long as flit linter ignore the sections it's not responsible from, it should works (tm).

On Sep 14, 2016 09:04, "Thomas Kluyver" notifications@github.com wrote:

Actually, one downside of moving to pyproject.toml is that it makes linting trickier, because what it contains depends on what buildsystem you use. We could probably build a linter that skips it entirely if it doesn't have a tool.flit section. But a more advanced solution would be a linter that can ask different packaging tools to check their respective metadata.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/takluyver/flit/issues/88#issuecomment-247063932, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUez6b9n-cbt3ZT3VX9uWOPZVX_BUPtks5qqBrugaJpZM4J7TFm .

[wwuck]

Is this still coming for pyproject.toml, or is it part of flit build now?

[takluyver]

I tend to use flit build as a linter, to run interactively at the command line. Something more would be required for editor integration, but that's not something I'm familiar with. It's kind of open for whoever wants to do it - either in Flit itself, or as a standalone project.

[wwuck]

This would potentially be a generic PEP-621 linter similar to how setup-cfg-fmt works for setup.cfg? The best I've found to use so far is toml-sort, but that is generic toml and can't do any validation of the metadata.

[takluyver]

That's a good point. There's still a little bit of Flit-specific additions ([tool.flit.module]) and restrictions (e.g. which fields can be dynamic), but a generic PEP 621 linter would provide most of the value and be useful for projects not using Flit as well.

[wwuck]

Would you expect such a linter to do formatting too, a la setup-cfg-fmt/tox-ini-fmt, or just linting and leave the formatting to eg. toml-sort?

Considering that the pyproject.toml format as it currently stands only has three main sections [build-system], [project]/[project.*], and [tool.*], if I did add formatting to this tool, it would be solely using toml_sort API for the equivalent of toml-sort --all --in-place. I don't see much need for a more customised sorting algorithm over what is done by toml-sort --all.

While an opinionated sorting of [project] table keys might be nice (eg. name at the top), the effort doesn't justify the reward for me. I could be convinced otherwise though if it were useful to others.

The linting aspect would be similar to what is done in flit build, ie. checking for PEP 621 required fields, no static definitions of fields marked dynamic, validating classifiers, etc.

[takluyver]

I'd imagine that linting (identifying potential problems) and autoformatting (changing the text) are separate functions for editor integration, but I don't really know much about what hooks editors have for this kind of thing. It's really up to whoever writes it and what they find most useful. :slightly_smiling_face:

[wwuck]

@takluyver It looks like someone else has done this before I had the chance to start on it.

https://pypi.org/project/validate-pyproject/

[abravalheri]

Please feel free to submit a PR for the flit specific parts :)