Support additional command line arguments about conda-devenv HOT 10 CLOSED

Hi @phausamann,

I like the idea! Indeed we also use environment variables to control certain aspects of the devenv file.

Perhaps we should also think about how to validate/require such arguments.

For example, we often use an environment variable to specify a Python version to use. Also, we often want that option to be mandatory, so users don't forget it:

{% set CONDA_PY = os.environ['CONDA_PY'] %}

...

{% if CONDA_PY == '36' %}
  - python ==3.6.7
{% else %}
  - python ==CONDA_PY_INVALID
{% endif %}

So if the user forgets to set CONDA_PY, he will get a KeyError, and if he specifies an invalid CONDA_PY, it will get an error from conda saying that CONDA_PY_INVALID is not a valid Python version.

This of course are all home-grown workarounds, which are fine for usage inside a development team which knows what's going on, but we might brainstorm a a more robust/builtin solution.

from conda-devenv.

An option with minimal implementation effort would probably be to have:

parser.add_argument(
    "-e",
    "--env_var",
    action="append",
)

and add those arguments to os.environ, so users could specify environment variables like this:

$ conda devenv -e PKG_DEV -e CONDA_PY=3.6

Alternatively, something like this would probably be more readable:

$ conda devenv -a dev -a py=3.6

with

- python ={{ required_arg("py", valid=("3.6", "3.7")) }}
{% if optional_arg("dev") %}
- ...
{% endif %}

from conda-devenv.

I like the second option, definitely!

@tadeu @prusse-martin what you guys think?

from conda-devenv.

I agree that the second option looks better =)
Also, I like the required_arg/optional_arg idea.

from conda-devenv.

I liked the first solution better (the one that allows defining extra environment variables through -e flags), because the implementation is simple and because it's an extension of a mechanism that is already used, instead of a new different mechanism.

Environment variables are nice because we can define them once and use conda devenv many times in the same shell session without having to pass extra arguments. The -e flags would be a nice extension for when we need to be more explicit about the variables being passed down.

from conda-devenv.

Now about a different issue, but if it's a problem how environment variables are handled by jinja (too "raw", needing to use os.environ), we could try to improve how they are handled, for example adding better error treatment, allowing selectors based on environment variables, also allowing pre-defined jinja variables based on environment variables, etc. It would be yet another extension complementing the -e feature.

from conda-devenv.

Using the -e approach how about:

• has_env(env_var_name) check if variable is defined;
• get_env(env_var_name, default=SENTRY, *, accepted_values=SENTRY) get the variable value, if variable is not defined return the default value, if not defined and no default given give an error (required variable?), if accepted values is defined and the return value is not one in that list give an error (not accepted value?);

I would say no to selectors (I assume you are referring to conda build meta.yaml like selectors), but since I do not remember any good argument against it, that is not a "hard no".

from conda-devenv.

get the variable value, if variable is not defined return the default value, if not defined and no default given give an error (required variable?), if accepted values is defined and the return value is not one in that list give an error (not accepted value?);

Yes to the inlined questions.

get_env is a nice shortcut that adds the opportunity to provide better error messages for enumerated and required variables.

has_env doesn't add much, being just a shortcut:

{% if "DEV" in os.environ %}

vs:

{% if has_env("DEV") %}

So I would suggest to don't bother with has_env for now, unless there's a use case where it simplifies things that I'm not seeing here.

Back to the original example then:

- python ={{ get_env("PY", valid=["3.6", "3.7"]) }}
{% if "DEV" in os.environ %}
- ...
{% endif %}

With that, we can also accept -e in the command line to set environment variables in the context of Jinja evaluation as @tadeu suggested:

conda devenv -e DEV=1 PY=3.6

@phausamann what do you think?

from conda-devenv.

I think get_env is a good solution, I'll start working on a PR.

from conda-devenv.

Awesome @phausamann, thanks! If you hit any roadblocks, feel free to open a PR anyway and we can discuss it over there.

from conda-devenv.