support for env cfg dependencies

[wiiznokes]

Problem

I would like to define dependencies based on environment variables

Proposed Solution

[env.'cfg(MY_ENV = SOMETHING)'.dependencies]

Notes

No response

[weihanglo]

Instead of proposing a solution, could you elaborate more on the workflow issue you encountered? Why optional dependencies don't work well for your case?

[wiiznokes]

The use case is :
I have a crate A which allows you to build a rust application. Depending on the option provided by the command line, it can set environment variables. The application can then depend on a crate B which uses these environment variables.

This isn't really possible to do with optional dependencies or it would be really counterintuitive. And will probably require that crate A is aware of the features offered by the application.

FYI, this feature would be useful for a possible feature in cargo-bundle

[epage]

Why the use case needs this solution and how this relates to cargo-bundle still don't seem to clear to me.

[wiiznokes]

Why the use case needs this solution and how this relates to cargo-bundle still don't seem to clear to me.

This is the comment that talk about a solution that would require this feature burtonageo/cargo-bundle#12 (comment)

This will enable application to have a compagnion crate that load ressource depending on ENV set by cargo bundle. But imaging one type of package need a dep to load the ressource (that actually the case for mac-os: https://github.com/burtonageo/cargo-bundle/pull/93/files)?

If we want to do it rn, the client app would need to mess with a lot of features, just to import the right feature of cargo-bundle-compagnion crate.
cargo bundle will then build the client-app by enabling the right feature.
With env cfg deps, the solution to this will be much simpler.

Of course, I am aware that this is a niche case, but I don't see too much of a disadvantage in adding this feature, other than adding complexity to cargo

[epage]

So the use case is switching between on-disk and bundled resource files.\

This is common in GUIs, games, etc. This is a fairly wide problem with a lot of people affected. I feel like this should be examined holistically, to see what each of the different ecosystems is doing and comparing their trade offs.

Example alternative solutions

• Somehow tying this to profiles so debug is local and release is bundled (e.g. profile-activated features)
• As this is a choice global to the build tree, feature flags can be annoying to manage for things like this but https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618 would be an improved alternative.