Thomas Kluyver

Fine on moving away from the deprecated method. I'm less keen on the idea of ignoring import errors: I'm trying to think about how getting the version number could be...

Either that, or limiting how packages can specify their version number so we can always get it without loading the whole package.

I've mentioned before that I'd consider breaking `setuptools_scm` type approaches. I haven't gone down that route yet, but I still might at some point. I know a lot of people...

I have a feeling we've discussed this before, but briefly: inspecting a package's version number is something I absolutely don't want to do magic, to involve shelling out to git...

I'm open to the idea, but note that ultimately I expect pip to handle installation again. You can already `pip install .` a Flit project from source. The missing piece...

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...

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

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...

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...

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...