Normalize usage of `project_name`
- Dominant language
- Python
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 40
Description
### What is the problem or limitation you are having?
Briefcase currently provides a global-level `project_name` configuration item.
This is currently a *required* item; however, it overlaps in purpose with the [required PEP 621 `name` key](https://packaging.python.org/en/latest/specifications/pyproject-toml/#declaring-project-metadata-the-project-table).
### Describe the solution you'd like
If a project defines a top level PEP 621 `name` field, that should be used as the "project name", and be merged into the global configuration as part of the PEP 621 configuration merge step. The value that has been provided should be [validated and normalised](https://packaging.python.org/en/latest/specifications/name-normalization/#names-and-normalization) as required by PEP 621.
If a project defines a `project_name` in the historical `[tool.briefcase]` format, that should continue to be accepted. However, if the provided value *cannot* be validated and normalised using PEP 621 rules, a warning should be raised (with a note that this may become an error in future).
In the new project wizard, the *app name* should be used as the default project name, not the formal name. The project name should be validated using the same rules as app name.
### Describe alternatives you've considered
Fully deprecate and ignore the `project_name` field. It's not actually being used for anything, as Briefcase has no real "project" level concepts. However, PEP 621 is organised at the level of "projects", so we should retain that abstraction; for small projects, "project" and "app" can be the same thing.
### Additional context
This is part of the broader #1235 effort to move to PEP 621 configuration.
Contributor guide
Research direction
Start by tracing the PEP 621 configuration merge and the new project wizard, with the broader #1235 effort as context. Verify how project_name and the PEP 621 name are currently handled, then identify the existing app-name validation path. Done means PEP 621 name values are normalized and merged, legacy values warn when invalid, and the wizard defaults and validates the project name as specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100