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

Nice way to handle env variable? #80

Closed
Prizrako opened this issue Apr 5, 2021 · 15 comments
Closed

Nice way to handle env variable? #80

Prizrako opened this issue Apr 5, 2021 · 15 comments

Comments

@Prizrako
Copy link

Prizrako commented Apr 5, 2021

Some methods to set environment varialbes for single command, instead of this:

os.Setenv("XB_AUTHOR_DATE", dateStr)
os.Setenv("XB_COMMITTER_DATE", dateStr)

Maybe in old shell way:

XB_AUTHOR_DATE="2021-04-05" XB_COMMITTER_DATE="2021-04-05" xb_push xxxx
@No-one-important
Copy link
Contributor

would
script.Env("variable", "value").Exec("command")
be a suitable solution

@bitfield
Copy link
Owner

bitfield commented Apr 3, 2022

I'm not seeing where this adds much value over, for example:

script.Exec("sh -c 'export MSG=hello; echo $MSG'").Stdout()

@No-one-important
Copy link
Contributor

on windows that syntax is not possible

@bitfield
Copy link
Owner

bitfield commented Apr 3, 2022

That's a fair point, but what about os.Setenv, for example?

@No-one-important
Copy link
Contributor

It works but I think it would cleaner to have it inline and builtin to the module.

@bitfield
Copy link
Owner

bitfield commented Apr 3, 2022

Useful abstractions, as John Ousterhout says, should be deep: they should conceal lots of functionality behind a simple API. Is there any way we could do more than simply call os.Setenv? Some example programs that need to set their environment would be useful. What about reading an envfile, for example?

@josegonzalez
Copy link

I think it might be nice to not use os.Setenv() and instead only set them for a Pipeline - maybe something like a wrapper around script.Exec("sh -c 'export KEY=value; true'"), but for potentially multiple key/value pairs? In this way, we scope environment variables to just the pipeline rather than the entire golang process that is invoking/utilizing the pipeline.

Note that the wrapper would probably need to properly escape the environment variables, so it wouldn't be as simple as a fmt.Sprintf() call. Maybe thats enough deepness for it to be implemented?

@bitfield
Copy link
Owner

That sounds good, @josegonzalez—can you write a short piece of example code to show what you mean?

@josegonzalez
Copy link

Maybe something like the following:

environ := map[string]string{
  "HASURA_GRAPHQL_JWT_SECRET": "{\"type\": \"HS256\", \"key\": \"256BITKEYHERE$\"}"
}
contents, err := script.Env(env).Exec("env")

@bitfield
Copy link
Owner

Okay, but this looks pretty similar to:

os.Setenv("HASURA_GRAPHQL_JWT_SECRET", `{"type": "HS256", "key": "256BITKEYHERE$"}`)
contents, err := script.Exec("env")

Can you describe what problem you think an Env method on the pipe would be solving here?

@No-one-important
Copy link
Contributor

os.Setenv would be global to the entire script this would allow it be local to the pipe

@bitfield
Copy link
Owner

Okay, but why is that important? Can you think of a situation where you'd want to set some environment variable for a command run by a pipe, but not for the program as a whole?

@No-one-important
Copy link
Contributor

I'm not sure of the usecases but it just allows the same flexibility that the bash syntax allows but for all OSs

@bitfield
Copy link
Owner

Well, if there are no use cases for something, that's just another way of saying we don't need it, isn't it? There are lots of feature ideas that aren't bad in themselves—they're great features! It's just that we don't need them, so we don't add them.

@bitfield
Copy link
Owner

bitfield commented Jun 2, 2022

Closing pending real use cases.

@bitfield bitfield closed this as completed Jun 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants