Add artifact parsing to Briefcase backend

[freakboy3742]

Adds a parse() implementation for the Briefcase ProjectSpec that adds the artefacts that can be generated natively.

The artefacts are listed based on what is generated natively on each platform - so, on macOS, it will tell you the artefacts that can be generated for macOS, iOS and Android; on Linux, it will give you the native platform format (e.g., RPM or DEB), plus Flatpak and Android; and so on.

This list won't be 100% accurate, as you can use Docker to cross-build Linux packages on other distros, and on macOS.

It won't include an artefact if there's no configuration, or if there's an explicit "supported = False" declaration for the platform.

It's not clear to me that there's anything else that should be added; I don't think anything Briefcase has defined counts as "content", but I might be misunderstanding the intention here.

[martindurant]

Thanks for posting! I have not had a chance to look in detail yet...

On the question of artefact types and what should be included: whether all the deployable things are a single type but with some "target" parameter or different types as you have them.
Similarly, you ask about non-package dependencies. So far we have four types of "environment" (pip, conda, npm, rust/crago), so it could be another one. However it's different because it's something you need only while building; also that each output artifact will need different ones.

These are conversation points it would be nice to have a number of voices on.

Finally, whether you should only list artifacts that can be made on the current platform. I think you probably want to include all, since it is something the project defines, and we don't necessarily want to build any, or might move the project elsewhere. For example, we can scan a uv project without having uv installed, which is a similar if not exactly the same situation.

[freakboy3742]

On the question of artefact types and what should be included: whether all the deployable things are a single type but with some "target" parameter or different types as you have them. Similarly, you ask about non-package dependencies. So far we have four types of "environment" (pip, conda, npm, rust/crago), so it could be another one. However it's different because it's something you need only while building; also that each output artifact will need different ones.

So what would represent an "Environment" for Briefcase?

• A macOS machine?
• A macOS machine with Xcode 16.0+?
• A macOS machine with Xcode 16.0+ and a macOS SDK 15.0 or higher installed?
• A macOS machine with Xcode 16.0+ and a macOS SDK 15.0 or higher and homebrew with an install of [insert list of tools]?

If the environmental dependencies are part of the spec - how are they determined if they aren't included in project metadata? For example, Briefcase includes checks to make sure that the Xcode version is sufficient for a given project, but that doesn't necessary manifest in the project configuration in a form that is parseable. Does that mean the Briefcase "minimum Xcode version" needs to be duplicated in projspec? Is projspec responsible for determining if that requirement is satisfied, or just defining that the requirement exists?

These are conversation points it would be nice to have a number of voices on.

I'm happy to be a voice in a room, and provide any feedback that might be helpful.

FWIW, the piece of the puzzle I'm not fully understanding yet is the intended use case for projspec. I appreciate that the project is in early stages, so there's a lot of work that still needs to be done, and there are pieces that are still missing. As it stands, the documentation tells me I can run projspec --summary --walk, and that will tell me a directory contains a Conda project, and a Git repo, and a Conda recipe, and so on ... but what do I do with that information? Why is it useful? What/who is the consumer of the information that has been parsed?

There's a bunch of tooling here to parse project files in different formats; but it's not clear how that parsed detail will be used - and that usage is going to strongly influence what structure, format, and level of detail the parsed content will need to take.

I've got some theories based on what I've seen in the code - that the end game is a "unified artefact building interface" (or, at least, a metadata generator that could feed such an interface); but even in that definition, working out what is or isn't in scope leads to some interesting follow up questions.

Finally, whether you should only list artifacts that can be made on the current platform. I think you probably want to include all, since it is something the project defines, and we don't necessarily want to build any, or might move the project elsewhere. For example, we can scan a uv project without having uv installed, which is a similar if not exactly the same situation.

I'm not sure I agree on that one. If I'm on a macOS machine, and I don't have uv installed, I could build a package with uv if I were to install the relevant tools. The tools exist, they're just not installed. However, I won't ever be able to build a Windows MSI, because the tooling just isn't available.

Even in the uv case - if I'm on macOS, I would be able to generate a wheel... but only a py3_none_* or macosx_*_* wheel. I wouldn't be able to generate a win_* or win32 wheel - again, because the tooling to produce a win_*/win32 wheel cannot exist on a macOS machine.