Parse environment variable replacement tokens in .snag.yml

[robertoandrade]

Do you guys think there's value in using environment variables replacement tokens inside .snag.yml so I can have the paths to scripts be configurable per user environment?

Is there any other way you would rather have this be passed to snag so it knows where to look for the files other than adding them to the PATH?

[zabawaba99]

I think exporting variables in the shell that snag is running in or passing variables directly to snag might be a better approach than having environment variables in the .snag.yml.

Have you tried doing something like:

PATH=$PATH:/path/to/my/scripts snag

[Tonkpils]

@zabawaba99 if that works then that'd be sweet. Does spawning off a new process to handle the request take the global env vars or would it include the one defined when calling the snag command.

[zabawaba99]

I've used the snippet that I posted before. If I remember correctly, the exec package takes a snapshot of the current environment and passes it along to the process it spawns.

[Tonkpils]

@robertoandrade does that work for you or do you still see value in allowing env vars in the snag file?

[robertoandrade]

well, say I wanted to pass a parameter to one of the commands... that was available as an env variable... say: - doIt $SOME_ENV_INFO.

For me to be able to pre-set the env variables and have them be picked up by doIt, I'd need to then wrap the command in a shell script to be able to pull the variable before passing in to the thing I wanted executed in the first place.

Your suggestion works well for PATH, but I don't think it addresses the other use cases.

[Tonkpils]

@robertoandrade I think I understand your use case a bit better now. @zabawaba99 let's chat and think of possible ways to approach this or if you already have thoughts on how to solve this let me know. I'd be happy to see a PR for this.

[zabawaba99]

I see the issue now, using - doIt $SOME_ENV_INFO doesn't work at the moment because the go exec command treats everything as strings. In order to support this we would need to make code changes when parsing the command, not necessarily the configuration itself.