Code Monkey home page Code Monkey logo

Comments (6)

mdsteele avatar mdsteele commented on September 24, 2024 2

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.

from cargo-bundle.

oluseyi avatar oluseyi commented on September 24, 2024

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

from cargo-bundle.

mdsteele avatar mdsteele commented on September 24, 2024

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.

from cargo-bundle.

yuhr avatar yuhr commented on September 24, 2024

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

from cargo-bundle.

GyulyVGC avatar GyulyVGC commented on September 24, 2024

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.

from cargo-bundle.

wiiznokes avatar wiiznokes commented on September 24, 2024

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:

from cargo-bundle.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.