You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed some design inconsistency between platforms while implementing #12. As mentioned in #92, it makes sense to having some option to generate not an installer but just a bundle, but then we need some clarification for the term "bundle". I think current implementation is like below:
Platform
What it's called
Can be run directly?
Windows
installer
need to be installed by itself
macOS
bundle
can be run directly, portable but can be installed by user
Debian
package
need to be installed by package manager
I think installing stuff is a little out of scope of cargo bundle subcommand and our primary business is just wrapping up essential files needed to run the application. Installers and packages are just to place these files onto specific directory and/or register the app to the "Installed Applications" list of user's OS. Ofcourse it would be great if cargo becomes capable of such stuff by using cargo-bundle though, it's a secondary or subsequent step.
There may be multiple steps in bundling process:
Build: already done by cargo build
Collect: copy the executable and the required resources to a separate directory
Sign (optional): codesign in platform-specific way, e.g. using rust-codesign
Pack (optional): generate installer or package, and sign it too if 2 is enabled
Deploy (optional but requires 2 and 3): upload to app store or similar, maybe out of scope
When a user runs cargo bundle, we just have to do upto 1. On macOS, this results in generating an *.app bundle, while others are just a bare directory containing an executable and resources. (But another concern is, we may have cargo bundle --bare option for macOS users who want just a bare directory)
Though, this is just a rough idea... Could someone advise?
The text was updated successfully, but these errors were encountered:
yuhr
changed the title
Concept: what is bundles?
Concept: what is bundle?
Nov 29, 2020
This is a good question. macOS has a concept of packages (.pkg files) that are similar to Debian packages or MSI installers. I don't have any great resources that describe the format, but there are several tools available for creating and extracting them.
Another example is disk images (.dmg files) on macOS which is the common way to distribute App bundles.
I've noticed some design inconsistency between platforms while implementing #12. As mentioned in #92, it makes sense to having some option to generate not an installer but just a bundle, but then we need some clarification for the term "bundle". I think current implementation is like below:
I think installing stuff is a little out of scope of
cargo bundle
subcommand and our primary business is just wrapping up essential files needed to run the application. Installers and packages are just to place these files onto specific directory and/or register the app to the "Installed Applications" list of user's OS. Ofcourse it would be great ifcargo
becomes capable of such stuff by usingcargo-bundle
though, it's a secondary or subsequent step.There may be multiple steps in bundling process:
cargo build
When a user runs
cargo bundle
, we just have to do upto 1. On macOS, this results in generating an*.app
bundle, while others are just a bare directory containing an executable and resources. (But another concern is, we may havecargo bundle --bare
option for macOS users who want just a bare directory)Though, this is just a rough idea... Could someone advise?
The text was updated successfully, but these errors were encountered: