Include more extensive dist-info for app package

[samschott]

Is your feature request related to a problem? Please describe. Sometimes the main app also doubles as a regular Python package with a setup.py / setup.cfg which defines additional metadata. In some cases, the package may depend on having this metadata available at runtime. At the moment, briefcase will pip-install all dependencies but uses a minimal install step for the app itself which essentially takes the metadata from pyproject.toml.

Describe the solution you'd like Would it be possible extend the app metadata for instance by pip-installing the app itself if a setup.py is found and then adding any additional briefcase-specific metadata afterwards? I realise that this may be a very niche issue and there could be good reasons against a pip-install (having less control over the install process, having possible console_script entry points installed, etc).

Describe alternatives you've considered Keep the install process as-is and generate any additional dist-info "manually" from a setup.py if found.

[freakboy3742]

This is an interesting suggestion. It would effectively mean having a "2 path" install process for the app itself - a "pip install" version, and a "briefcase install" version. Detecting which branch to use won't be quite as simple as "look for setup.py" - because the app could be packaged using Flit (or any other PEP517 compliant tool). However, looking for the [build-system] PEP517 descriptor should be sufficient; if that descriptor exists, we would use pip install . to package the app's code, and then augment the app metadata with the extra pieces that Briefcase can provide. Otherwise, we fall back to briefcase's install approach.

For the record, the reason why I avoided "normal" setup.py installation is because packaging an app is conceptually different from packaging a package that will be uploaded to PyPI. It's analogous to the difference between specifying a requirements.txt and specifying dependencies in install_requires. An "app" is closer to the website model of deployment - here's a collection of code and dependencies, deployed once - rather than a "package" that others will deploy into their own projects.

However, we've now had a couple of reports of people wanting to have projects that are both pip-installable and briefcase-packagable. It's definitely an edge case, but I think it's an edge case that is worth supporting if we can (and AFAICT, we can, without too much difficulty).

[samschott]

I have looked through the code and the briefcase docs a bit and can see how this may be difficult. Briefcase allows you to define multiple apps in the pyproject.toml which need not share any source code. On the other hand, a pip-installable package, as identified by a [build-system] descriptor, typically refers to a single Python package with the source code potentially defined in a setup.cfg or setup.py. Therefore, a pip-install may result in something completely different being installed than what was specified in the sources key of [tool.briefcase.app.<app name>].

One way around this would be to prefer the pip install for all apps defined in pyproject.toml and fall back to the specified source lists otherwise. But this could become very confusing to users.