beeware / beeware/briefcase

Adopt PEP 517 installation mechanisms for Briefcase app code

Open
#2,867 2 comments 1 reaction 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.