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

[Feature] Add a new command line argument to set environment variables #1054

Closed
frol opened this issue Jun 27, 2016 · 6 comments
Closed

[Feature] Add a new command line argument to set environment variables #1054

frol opened this issue Jun 27, 2016 · 6 comments
Labels
locked [bot] locked due to inactivity stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity

Comments

@frol
Copy link
Contributor

frol commented Jun 27, 2016

Currently, you can specify a list of passthrough environment variables in meta.yaml (build/script_env). However, there are use-cases when it is not feasible to list all possible env variables. One example of such a useful environment variable is MAKEFLAGS and it is even made into the conda-build core. Imagine you don't need to make extra PRs just to pass through a new build-system specific variable.

Please, consider the following syntax (copied from docker run command):

$ conda build --env "MAKEFLAGS=--jobs 4" --env "CPPFLAGS=-Wall -Werror" ./conda.recipe/

This way we won't worry about implicitly and unexpectedly passed settings from a host system. Also, there would be no need to list all sorts of possibly useful only for build systems env variables in recipes.

P.S. It might be also a good idea to implement a config file for conda-build where these environment variables and other useful settings can be saved and reused.

/cc @jschueller @groutr @msarahan @jakirkham

@msarahan
Copy link
Contributor

Yep, great idea. The limiting factor here has been time. See #966 for progress. This is one step behind #953 on my priority list, but I hope to get to it very soon.

@jakirkham
Copy link
Member

Yep, those both sound like great ideas, @frol. I'd much prefer we even specify MAKEFLAGS this way instead of having it setup for auto-passthrough.

@frol
Copy link
Contributor Author

frol commented Jun 27, 2016

@jakirkham That was also a part of the intention behind it. Currently, somebody can potentially hit some nasty issues if they use something fancy in their MAKEFLAGS.

@jschueller
Copy link
Contributor

jschueller commented Jun 27, 2016

In that case you may want to revert these: #917 conda/conda-docs#270

cc @jakirkham

@jakirkham
Copy link
Member

cc @ocefpaf

@github-actions
Copy link

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

  1. Verify that you can still reproduce the issue at hand
  2. Comment that the issue is still reproducible and include:
    - What OS and version you reproduced the issue on
    - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

@github-actions github-actions bot added the stale [bot] marked as stale due to inactivity label Jun 19, 2022
@github-actions github-actions bot added the stale::closed [bot] closed after being marked as stale label Jul 19, 2022
@github-actions github-actions bot added the locked [bot] locked due to inactivity label Jul 19, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity
Projects
None yet
Development

No branches or pull requests

4 participants