Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a cross-platform way to load bundled resources #12

Open
mdsteele opened this issue Feb 12, 2017 · 6 comments
Open

Provide a cross-platform way to load bundled resources #12

mdsteele opened this issue Feb 12, 2017 · 6 comments

Comments

@mdsteele
Copy link
Collaborator

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?

@oluseyi
Copy link
Contributor

oluseyi commented Mar 20, 2017

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

@mdsteele
Copy link
Collaborator Author

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.

@yuhr
Copy link

yuhr commented Oct 5, 2020

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

@mdsteele
Copy link
Collaborator Author

mdsteele commented Oct 5, 2020

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.

bors-servo added a commit to servo/core-foundation-rs that referenced this issue Oct 14, 2020
…tory-url, r=jdm

Add CFBundleCopyResourcesDirectoryURL

I need this because of burtonageo/cargo-bundle#12.
jdno added a commit to jdno/auto-traffic-control that referenced this issue Apr 5, 2022
Initially, the game will be distributed through itch.io [^1], a
platform for indie games. itch.io provides tools that make it easy to
publish and distribute a game to players, which massively reduces the
burden on us to produce builds and installers for the different
platforms.

A new GitHub Action has been created that runs when a new release is
created. Pre-releases are pushed to a beta channel on itch.io, while
regular releases are pushed to the main channel.

Releasing the game for macOS requires us to create an app bundle [^2],
which is done with `cargo-bundle`. `cargo-bundle` can automatically copy
resources into the bundle, but it is missing an API to access them
dynamically from the program [^3]. For this reason, the GitHub Action
moves the resources back so that they are next to the binary.

[^1]: https://jdno.itch.io/auto-traffic-control
[^2]: https://itch.io/docs/itch/integrating/platforms/macos.html
[^3]: burtonageo/cargo-bundle#12
@GyulyVGC
Copy link

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.

@wiiznokes
Copy link

wiiznokes commented Dec 10, 2023

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants