Adopt PEP 517 installation mechanisms for Briefcase app code
- 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 implements its own custom "installation" mechanism, defining a `sources` list, `test_sources` list, and custom conventions around entry points.
This replicates a lot of functionality and expectations that exist around PEP 517.
### Describe the solution you'd like
Briefcase should deprecate its own install mechanisms in favour of using PEP 517 interfaces. This would mean doing the equivalent of `pip install . --target ` in a packaged app, and `pip install -e .` for dev environments.
### Describe alternatives you've considered
Retain the status quo.
Briefcase could also *become* a PEP 517 compliant install tool. That's a much bigger task, and I'm not sure Briefcase has much to add in this space. However, it might be helpful as a "migration" approach - move all Briefcase's app installation code into a PEP 517 build backend, ultimately allowing for deprecation of that entire module.
### Additional context
Two open questions that need to be resolved:
1. How to handle test code. PEP 517 is silent on how to manage test code, since test code shouldn't normally be bundled with the package. We may need to retain `test_sources` handling.
2. How to handle app metadata that isn't part of the wheel metadata spec. For example, Briefcase makes a distinction between a "formal name" and an "app name"; there's no analog for this in the wheel metadata spec. This may be something where we should coordinate with the broader Python ecosystem to extend PEP 621.
Contributor guide
Research direction
Start by reviewing Briefcase's current custom installation mechanism, including the sources and test_sources lists and its entry-point conventions, then compare them with the PEP 517 interfaces used by pip install . --target and pip install -e .. Resolve how test code and app metadata outside wheel metadata should be handled. Done means the custom mechanism is deprecated in favor of PEP 517 installation, with those open questions addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100