cargo-bundle icon indicating copy to clipboard operation
cargo-bundle copied to clipboard

Provide a cross-platform way to load bundled resources

Open mdsteele opened this issue 7 years ago • 6 comments

Seems like one of the strengths of cargo-bundle is being able to easily handle resource files in a cross-platform way (something I've found to be a pain to deal with on previous, non-Rust projects). While it already provides an easy way to include arbitrary resource files in the bundle, that still leaves the other half of the job: finding and loading those resources once the application is running.

A few ideas for what this could look like:

  • cargo-bundle could provide a companion library (since a single crate can have both a binary and a library) that programs can depend on for loading resources. Since this library would share code with the cargo-bundle binary, they'd be easy to keep in sync.
  • The simplest API for this library that comes to mind would be function that takes a file path/URL as written in the resources field of the bundle spec, and returns a path to where that file was actually placed by the bundle, depending on what system you're running on (so on OSX it would use e.g. CFBundleCopyResourcesDirectoryURL, on Debian it would look in /usr/lib/package_name/, etc). That way your actual application code doesn't need to care about what OS it's running on.
  • Ideally, this library would also work correctly if you run your application via cargo run rather than bundling it first, in which case it would load the resources from their original location as written in the resources field of the bundle spec. (Although I'm not sure off the top of my head what is the best way for the library to detect this situation).

Thoughts?

mdsteele avatar Feb 12 '17 17:02 mdsteele

This is a very good idea. No concerns beyond distinguishing between cargo run and direct execution come to mind.

oluseyi avatar Mar 20 '17 02:03 oluseyi

Looks like cargo sets several environment variables when executing commands (including cargo run) that wouldn't normally be present when running the binary directly. So the library could check e.g. std::env::var_os("CARGO").is_some() to determine if the binary is being run via cargo run.

mdsteele avatar Apr 28 '17 18:04 mdsteele

This feature is a must-be. Is there any ongoing development for this?

yuhr avatar Oct 05 '20 07:10 yuhr

I'm not aware of any work being done on this. If you'd like to try to implement it, pull-requests would be welcome.

mdsteele avatar Oct 05 '20 15:10 mdsteele

Seems like one of the strengths of cargo-bundle is being able to easily handle resource files in a cross-platform way (something I've found to be a pain to deal with on previous, non-Rust projects). While it already provides an easy way to include arbitrary resource files in the bundle, that still leaves the other half of the job: finding and loading those resources once the application is running.

A few ideas for what this could look like:

  • cargo-bundle could provide a companion library (since a single crate can have both a binary and a library) that programs can depend on for loading resources. Since this library would share code with the cargo-bundle binary, they'd be easy to keep in sync.
  • The simplest API for this library that comes to mind would be function that takes a file path/URL as written in the resources field of the bundle spec, and returns a path to where that file was actually placed by the bundle, depending on what system you're running on (so on OSX it would use e.g. CFBundleCopyResourcesDirectoryURL, on Debian it would look in /usr/lib/package_name/, etc). That way your actual application code doesn't need to care about what OS it's running on.
  • Ideally, this library would also work correctly if you run your application via cargo run rather than bundling it first, in which case it would load the resources from their original location as written in the resources field of the bundle spec. (Although I'm not sure off the top of my head what is the best way for the library to detect this situation).

Thoughts?

As of today, is it possible to load bundled resources at runtime?

Also, when I run the bundle application, the current directory seems to be the root (/), no matter where the bundle is launched. I got this information with the command std::env::current_dir(). I would like the application to have as current directory the folder from where I launch it.

GyulyVGC avatar Oct 24 '22 10:10 GyulyVGC

I think this should be handled primarily with environment variables. Since there can be several types of packages on the same OS, we are forced to depend on the cargo bundle arguments. For example, for build deb

  • cargo bundle --format deb
  • cargo bundle will then set a variable: env::set_var(PACKAGE_TYPE, "DEB");
  • the crate companion will then use it in its code (with a build.rs file). If the variable is not set, this means that cargo run was used

Notes:

  • The variable in question could directly provide the full path, but it would need to be set in several places in the code
  • I really like the idea of providing a library by adding a lib.rs file, but for now, this will add all the cargo-bundle dependencies to our applications, which seems very unnecessary.

refs:

  • cargo issue : https://github.com/rust-lang/cargo/issues/1982
  • my app which use env var to do this: https://github.com/wiiznokes/fan-control

wiiznokes avatar Dec 10 '23 19:12 wiiznokes