cargo-druid

[cmyr]

cargo-druid

This is a very preliminary sketch of cargo-druid, a tool for managing druid projects.

cargo-druid is a cargo plugin. Although its scope will likely increase over time. Its initial focus is on bundling up various resources and generating native packages/app bundles for your target platform(s).

Rationale

A desktop application is more than just an executable; it is also a collection of other assets such as an Icon, a set of entitlements and capabilities, localization files, etcetera. Significantly, different platforms have very different conventions around what constitutes an application package or bundle (from now on, an app) on that platform. cargo-druid is a tool that reads per-platform configuration options, and generates these packages.

Druid.toml

Druid applications will have a Druid.toml file in their top-level directory; that is, alongside Cargo.toml. Druid.toml is responsible for describing various attributes or capabilities of your application, such as (possibly) the types of files it can open, the locales it supports, the permissions it requires, or the locations of its assets. Some of this stuff may be inferred, and some of it may be explicit; the exact structure of this manifest is very much TBD.

The structure of a druid project

As part of cargo-druid, we will also standardize the structure of a druid project; that is, we will describe a directory structure with standard locations for things like localization files, images, and other assets. cargo-druid will be able to create an empty project for you.

asset bundling

This has a separate issue (#397) but it will be tightly coupled with the cargo-druid project, since cargo-druid will be responsible for actually gathering up the required assets for a given platform and putting them in the places where druid can find them.

capabilities

cargo-druid is intended to mimic the API we already know from cargo. Some examples of commands that might exist:

# create a new druid project in an existing directory?
$ cargo druid init
# create a new druid project, period
$ cargo druid new
# rebuild assets and put them somewhere we can find them, then run the app
$ cargo druid run
# does this do anything different from just cargo test?
$ cargo druid test
# create a native app bundle.
$ cargo druid package
# we can at least dream
$ cargo druid publish
# verify that our directory structure is right and files are in the right place
# maybe we want a different name for this?
$ cargo druid check

This is intended mostly to spark the imagination; much is possible!

other things to consider:

• cross compilation: This would be nice to have but I haven't thought about it at all.
• code signing: how hard could this possibly be

[xStrom]

I would like some clarifications on scope. What exactly is a bundle? Is this just a collection of files that are needed for correct behavior or does this also include installation/management?

[ForLoveOfCats]

There is also the topic of applications being able to store configuration files and other runtime created files in platform idiomatic locations. While that I feel is probably more in the wheelhouse of druid-shell it's at least tangentially relevant to this discussion.

[cmyr]

@xStrom I get this confusion. This issue is about the tool that will create packages and installers. I'm using the term 'bundle' to describe the stuff in #397, which is really just about runtime access to app resources like custom images.

@ForLoveOfCats An API for file saving (and general state persistence) is definitely something we'll want, but I think we can treat that as a separate issue. Worth having an issue for it though, I'll open something.

[alerque]

Shouldn't this probably be a separate project? Have you considered generalizing this? The problems listed are not specific to druid, or even to desktop UI apps. I created a CLI using Rust. Just getting cargo to generate the right shell completion files from build.rs was tricky enough, it certainly didn't lend a hand in gathering everything up and bundling. I ended up doing that with GNU autotools. There are plenty of build systems with the chops to build app packages, but if you are going to make something specific to Cargo does it need to be limited to Driuid too?

[cmyr]

@alerque that's a great question. My feeling is that we might be opinionated around some things (like expected directory structure, localization process) that would make it harder to generalize, but I do think that whatever can be made general purpose should be, and I want to lean on existing parts of the ecosystem (like cargo-bundle) wherever possible.

How I suspect this will go is that we'll do a pass where we're focused on druid, and then once we have a better sense of what we're doing we can consider breaking more of it up into separate, more general tools?

[JAicewizard]

It is probably worth having 2 separate output kinds, one is an executable (.app/exe), and an installer (.msi, .dms, and all the various Linux installers and distros). because most packaging systems produce installers, while a single executable might suffice for the purpose.