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

null as default value for env interpolation #230

Closed
apsdehal opened this issue Apr 23, 2020 · 9 comments
Closed

null as default value for env interpolation #230

apsdehal opened this issue Apr 23, 2020 · 9 comments
Labels
enhancement New feature or request
Milestone

Comments

@apsdehal
Copy link

If I pass null as default value to env interpolation, as with yaml, I expect to get the value as None, but I get the string 'null'.

from omegaconf import OmegaConf
a = OmegaConf.create({"a": "${env:a, null}"})
print(a.a) # prints "null"

If this is a not a bug, how can I specify None as the default value?

@omry
Copy link
Owner

omry commented Apr 23, 2020

smells like a bug to me.

@omry omry added this to the OmegaConf 2.0 milestone Apr 23, 2020
@omry
Copy link
Owner

omry commented Apr 23, 2020

PR welcome :)

@omry
Copy link
Owner

omry commented Apr 23, 2020

The docs does not specify the type of arguments and currently they are strings.

OmegaConf.register_resolver("concat", lambda x,y: print(type(x), type(y), x+y))
cfg = OmegaConf.create({"foo" : "${concat:10,foo}"})
<class 'str'> <class 'str'> 10foo
cfg.foo

There is a case to make for converting the strings to a primitive or even with yaml_decode but the parsing now is very primitive and I really don't want to support something as sophisticated as yaml there.

Let me think about it, I am leaning toward keeping things as is. giving arbitrary types may not be simpler for the receiving code. for example the registered resolver will need to handle a plathora of types based on what the user is passing in which will probably make most cases more complicated, only to simplify one case (yours).

@apsdehal
Copy link
Author

A current workaround for this is to pass empty string as default parameter. This will give empty string back. Then if will evaluate it directly to false.

@omry
Copy link
Owner

omry commented Apr 23, 2020

default value where? code? config?

@apsdehal
Copy link
Author

OmegaConf.create({"a": "${env:a,}"})

@omry
Copy link
Owner

omry commented Apr 24, 2020

Okay, I can consider adding a flag to register resolver that will cause the variables to be converted to primitives for 2.1.

@omry omry modified the milestones: OmegaConf 2.0, OmegaConf 2.1 Apr 24, 2020
@omry omry added the enhancement New feature or request label May 25, 2020
@omry omry changed the title [bug] null as default value for env interpolation null as default value for env interpolation Jun 20, 2020
@omry
Copy link
Owner

omry commented Feb 3, 2021

blocked on #445

@omry omry added the blocked label Feb 3, 2021
odelalleau added a commit to odelalleau/omegaconf that referenced this issue Feb 10, 2021
odelalleau added a commit to odelalleau/omegaconf that referenced this issue Feb 10, 2021
@omry omry added In progress and removed blocked labels Feb 10, 2021
odelalleau added a commit to odelalleau/omegaconf that referenced this issue Feb 11, 2021
omry pushed a commit that referenced this issue Feb 12, 2021
* Add a grammar to parse interpolations
* Add support for nested interpolations
* Deprecate register_resolver() and introduce new_register_resolver() (that allows resolvers to use non-string arguments, and to decide whether or not to use the cache)
* The `env` resolver now parses environment variables in a way that is consistent with the new interpolation grammar

Fixes #100 #230 #266 #318
@omry omry closed this as completed Feb 17, 2021
@odelalleau
Copy link
Collaborator

odelalleau commented Mar 31, 2021

Just a note that as of 2.1, one should use the new oc.env resolver in order to be able to use a default value of null. See #573 for migration instructions.

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

No branches or pull requests

4 participants