`application-import-names` should fall back to `project.name` if `tool.poetry.name` is not specified

[bkeryan]

Using poetry-plugin-migrate to migrate from Poetry 1.x to Poetry 2.x moves the project name from tool.poetry.name to project.name. The code in ni-python-styleguide for querying application-import-names does not fall back to project.name, so this changes how imports are sorted.

Workaround: specify application-import-names

[bkeryan]

PEP 794 - Import Name Metadata adds core metadata fields for Import-Names and Import-Namespaces, with corresponding pyproject.toml fields of project.import-names and project.import-namespaces.

I think it would make sense for ni-python-styleguide to check the following fields, in decreasing precedence:

• tool.ni-python-styleguide.application-import-names (tool-specific, always takes precedence)
• project.import-names
• project.name
• tool.poetry.name

I also think it might make sense to deprecate tool.ni-python-styleguide.application-import-names and emit a warning saying to set project.import-names instead.

I don't think it makes sense to treat project.import-namespaces as first-party imports because they could be either first-party or third-party depending on which subpackages/submodules you are using. It's reasonable to import from a namespace package, though: from X.Y import Z is a first-party import when X.Y.Z is in import-names and third-party otherwise. from ni.measurementlink import pin_map_context_pb2 is a real example of this.

Cc: @mshafer-NI

[bkeryan]

@mshafer-NI On further thought, maybe we shouldn't deprecate tool.ni-python-styleguide.application-import-names. Some projects specify additional import names for imports that are not part of the distribution package, such as tests and codegen tools. (However, it looks like ni-python-styleguide always adds ,tests, so specifying tests is unnecessary.) If you put these in project.import-names, then they show up in the distribution package's Import-Names metadata.

Keeping tool.ni-python-styleguide.application-import-names would allow these projects to control ni-python-styleguide separately from the distribution package metadata.

Another idea is to have an ni-python-styleguide field that is merged with project.import-names, such as a tool.ni-python-styleguide.extend-import-names.