User defaults question

[frosty geyser]

Hi everyone, is there a plan to make user defaults work for functions and not just constructors ? I love the idea having defaults but sometimes it doesn't make sense to have all possible variables (that could be defaulted) at the constructor level.

[chrome yoke]

You can set user defaults for any function 🙂 Sorry that we didn't properly document this yet...

If you add the function name in the env var name, it should work.

For example:

foo().bar(baz: "hello")

FOO_BAR_BAZ="hello"

[frosty geyser]

love it ! Thanks @chrome yoke . Just one more question, is there a way to have it load from env variables directly or does it have to go through .env file

i basically want to avoid doing env > .env in my pipeline

[chrome yoke]

At the moment, .env file only. But:

1. @crystal cradle just contributed a PR to allow that .env file to itself reference system variables. So that will be available in the next release (planned for later this week)
2. It seems reasonable to also add support for loading user defaults directly from the system environment. We would just need to figure out the practicality of it, especially from a caching and security POV (basically how do we avoid doing the equivalent of env > .env in the dagger engine code 😛 )

Another medium we're considering for setting user defaults, is a config file

[frosty geyser]

maybe the default pragma could be useful default="env:FOO"

this avoid loading all env but only the ones the module is actively looking for

[chrome yoke]

I understand the desire for that, but we designed the whole user defaults system specifically to not allow a function to access env variables outside its sandbox. We want the user to do the mapping themselves, for safety and portability reasons

if you think of user defaults as configuration, it makes more sense.

[crystal cradle]

and loading only the specific envs will help with cache re-use. In the next release it should be possible to define an .env as:

FOO="{$FOO}"

which will pull in the host's env value only for FOO which will allow one to use the dagger env-file primitive without having the cache key changing if a different unrelated host env value changes.

[chrome yoke]

Right, it's super useful to have a scope

[frosty geyser]

Totally understand the design 🙂 i think with @crystal cradle 's solution it's a good workaround for my usecase 🙂

[frosty geyser]

@chrome yoke is there a difference in behavior while using default on an "external" module using dagger -m call ... ? I can't get that to load the variables

it doesnt seem to be picking up the .env file

[chrome yoke]

For safety reasons, dagger never interprets a remote .env. Only local.

You can still set defaults for a remotely loaded module, by writing them to a .env outside the module directory, and prefixing the var names with the module name

The .env just needs to be available with a find-up search (standard .env search rules)

For example:

echo 'daggerDev_engineDev_test_run=TestUserDefaults' >> ~/.env
dagger -m github.com/dagger/dagger call engine-dev test

Note: daggerDev is the name of the module in github.com/dagger/dagger

[frosty geyser]

thanks for sending this 🙂 it's really helpful

will give that a shot !

[chrome yoke]

As a nice side effect, this also means you can manage user defaults for multiple modules in a single .env file

[frosty geyser]

it's a feature. not a bug !

[frosty geyser]

got it to work ! thanks @chrome yoke