Add "version" command to briefcase

[saroad2]

Taking inspiration from poetry, we should implement a "version" command for "briefcase". For example, given the following pyproject.toml file:

[tool.briefcase]
project_name = "EddingtonGUI"
bundle = "com.eddington_gui"
version = "0.0.2.dev0"
url = "https://eddington_gui.com/eddington_gui"
license = "Apache Software License"
author = 'Sagi Shadur'
author_email = "[email protected]"

The command briefcase version should output "0.0.2.dev0"

[saroad2]

@freakboy3742 , can I implement this command?

[freakboy3742]

+1 to the feature idea. Longer term, adding "bumping" options analogous to poetry's would also make sense.

I have a mild concern about differentiating between briefcase version and briefcase --version; from a UX perspective, it's not immediately obvious which is Briefcase's version, and which is the project's version.

Would gathering "project management" commands under briefcase project or briefcase manage namespace make sense to you as a user? That would make the version command briefcase project version or briefcase manage version. That provides a little more context to the "version" request; and also provides an entry point for other project management options in future.

[saroad2]

I prefer briefcase project version much better than briefcase manage version, but I must say that I think users will understand the difference between briefcase version and briefcase --version. This is absolutely up to you.

Once you decide what syntax you want the command to be, I'll implement it.

[freakboy3742]

In which case - lets go with briefcase project version.

[saroad2]

I started to implement this feature and unfortunately hit a wall. When I run briefcase project version, briefcase interpret version as the platform... This is accruing because of the way cmdline.py parser is implemented.

As I see it, there are 2 optional solutions to the problem:

The first one to change the command to my initial suggestion of using the command briefcase version

The more complicated option is to split the parse_cmdline function to 3 stages:

1. Parse only the command first (new, dev, create, etc.)
2. If it is a platform-based command: 2.1 Parse platform and output format
3. Parse specific command flags

As always, this is up to your consideration.

[freakboy3742]

I tend to agree that splitting up the command processing makes a sense. Parsing the platform is something that should only be occurring on the "platform-based" commands, so it makes sense to factor that out, especially if it permits other command types (like project)

[freakboy3742]

#424 has raised a related use-case - getting properties of the built app, like the path to the releasable artefact.

That got me thinking - although the version number can be specified at the level of the project, it can be overridden at the level of the app. I wonder if it might be necessary to have a briefcase project and briefcase app to expose project and app-level settings, respectively. That would allow for briefcase project version; but also briefcase app version -a myapp and briefcase app output_path -a myapp.

[saroad2]

That sounds reasonable 😃 .

I'm currently working on a big refactoring to parse_cmdline so it could handle commands without platform (such as briefcase app and briefcase project, but also briefcase create and briefcase new). In order to get there, working on the following:

1. Adding code coverage to Briefcase - see here #417
2. Doing the refactoring for parse_cmdline while making sure that test coverage is maintained.
3. Adding the briefcase project command.

I'll let you know it is going.

[saroad2]

I'm considering moving briefcase endpoint to use click instead of argparse. It has many neat abilities, and I think it should make the code much clearer. It should be a quite big change, but I think it worth it.

What do you think?

[freakboy3742]

I haven't used click for anything serious, so I don't really have an opinion. I've heard good things, so if you can make it work, then I'm definitely up for considering it.

FWIW, I did evaluate it when doing the 0.3 rebuild for briefcase, and decided against it, for much the same reason that the argparse implementation is very complex.

I am definitely up for simplified code - you won't get any argument out of me that the argparse implementation that we now have is complex. However, I'd argue it's complex for a reason - I spent a lot of time sweating the small details of the end-user experience for command line options, and being able to provide complete and correct option lists and help. I'm completely willing to accept I might have missed an obvious option.

Ultimately, I think this is a case where code will do a lot more to convince me. Replacing the internals of briefcase is obviously a big job; so before you embark on that, perhaps a simple proof of concept might be the way forward. It doesn't need to be tested or integrated with the rest of Briefcase logic - but if you can demonstrate what the click implementation of command parsing would look like, I can see what is possible (or point out the flaws that I see).