beeware / beeware/briefcase

Expose more features of the underlying tools managed by Briefcase

Open
#747 4 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

The `briefcase upgrade` command provides a convenient interface to force an update of the tools Briefcase is managing. However, there are other "tool related" features that would be helpful to expose:

* Versions of currently managed tools
* Versions of tools that exist, but Briefcase can't update (e.g., Xcode)
* Versions of internal components (e.g., the SDKs managed by the Android SDKmanager
* The ability to *execute* tools (e.g., sdkmanager)

We currently compute the version of tools as part of the verification process, but we don't generally surface that information except in debug mode.

The Android backend will dump the contents of the sdkmanger during debug, but doesn't expose a "non-debug" way to list the same information.

The only way to easily invoke the Android SDK manager at present is to use `-v` to see the command line and environment used to issue commands, and manually reproduce those commands.

There isn't an easy way to start a Docker shell in a project's environment.

**Describe the solution you'd like**

One option would be to replace the `briefcase upgrade` command with a new `briefcase tool` command. This new command would allow for the following usage patterns:

* `briefcase tool --list` - list all tools used by Briefcase, including the version numbers.
* `briefcase tool --upgrade` - upgrade all tools currently managed by Briefcase
* `briefcase tool --upgrade ` - upgrade all tools currently managed by Briefcase
* `briefcase tool --run ` - run a specific tool with the provided arguments. This should configure any

**Describe alternatives you've considered**

It may be preferable retain the `upgrade` command as-is, extend it to include *more* of the managed tools (e.g., it doesn't currently display the Xcode version because there's no upgrade path), and include the version numbers as part of the `upgrade --list` output.

The execution of specific tools would then be a feature of a specific backend - probably the `run` command. For example `briefcase run android --sdkmanager ` would invoke the SDK manager. This would then allow each backend to provide very specific tool executions, rather than needing to expose a generic API for gathering tools into the upgrade command.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.