Stream: wasi

Topic: Preview 2 environment variables

Joel Dice (Dec 14 2022 at 15:44):

I've been working on the Preview 2 host implementation and have been thinking about how to support environment variables. @Dan Gohman reminded me that the current plan is to use WIT star imports to represent env variables so that each variable is represented by a zero-argument function to be exported by the host. Thus a guest component will need to indicate which variables it will need by importing a function for each, and the host will match those up with the variables it has, throwing an instantiation error if it can't meet the guest's needs. I have two questions about this:

• Is my description above accurate?
• How will will the preview1->preview2 adapter work? A preview1-based module doesn't advertise which variables it needs, and it might not even know what it needs; e.g. it might just load them into a map and ship them off somewhere dynamically.

I seem to recall a discussion that there would be two Preview 2 APIs for getting variables: a static one as described above, and a dynamic one to handle other cases. Perhaps that latter is what I'm looking for here. Something like dynamic-environ-get: func() -> list<(string, string)>? And presumably the preview1->preview2 adapter would use that instead of the static, star-import-based API?

Alex Crichton (Dec 14 2022 at 15:49):

My personal current plan has been to not implement star imports at this time as while they sound nice I don't have any idea how to implement them concretely, so for the near-term in the same manner as we don't have async quite yet I think it would be better to plan to not have star imports. How that affects the adapter though I'm not certain.

Alex Crichton (Dec 14 2022 at 15:49):

Not to say that star imports can't be implemented of course, but someone would need to champion it end-to-end to have WASI depend on it

Lann Martin (Dec 14 2022 at 15:54):

Dynamic access to environment variables seems pretty necessary to me.

Lann Martin (Dec 14 2022 at 15:55):

I wrote a bit of code yesterday that needed to iterate over environ to pattern match keys.

Alex Crichton (Dec 14 2022 at 15:59):

Personally I don't have an issue with dynamic-environ-get as you've proposed. A halfway alternative is to pass env vars to the command export in the same manner as argv but I say halfway since env vars I think are important for non-commands and there's otherwise no mechanism for non-commands to get their env vars

Joel Dice (Dec 14 2022 at 16:00):

OK, so sounds like we need a dynamic function to get all the env vars no matter what, and someday we'll add a static, star-import-based API too, but probably not in time for Preview 2 unless someone champions it. I'll go ahead and add the dynamic function to wasi.wit.

Lann Martin (Dec 14 2022 at 16:01):

bikesheding the name: maybe just environ-get? It is pretty clearly "dynamic"...

Joel Dice (Dec 14 2022 at 16:01):

@Alex Crichton I can pass them in via WasiCtx for the time being. Happy to add another argument to command too, if desired.

Alex Crichton (Dec 14 2022 at 16:02):

To clarify though Dan's had the most thoughts on this I think historically, so I'd recommend double-checking with at least him before fully committing

Alex Crichton (Dec 14 2022 at 16:03):

but yeah I think configuring env vars in WasiCtx is fine for now

Last updated: Dec 23 2024 at 13:07 UTC