pixi
pixi copied to clipboard
prefix-dev
feat: add env to activation table
Not sure about this addition. Would expect it to be a lot smarter but now it just sets simple environment variables.
I would expect it to expand variables if you would do:
[activation.env]
PATH = "bla/bli/blu:$PATH"
@wolfv What do you think? Merge this already (after adding docs) or figuring out a better parsing solution for the variables?
@baszalmstra Do you have some smart ideas on how to easily and in a cross-platform way, add these env vars? Specifically reusing existing variables:
[activation]
env = { PATH = "$PIXI_PROJECT_ROOT/extra/path:$PATH", MODEL_LOCATION = "$PIXI_PROJECT_ROOT/models"}
One of my ideas would be parsing the strings ourself and use rusts std::env::var(), what do you think about that?
@baszalmstra Do you have some smart ideas on how to easily and in a cross-platform way, add these env vars? Specifically reusing existing variables:
Yeah that could work but its a little bit more tricky because on Windows the separator for the PATH variable is not :' but ;` so you'd have to normalize that too. How do other task executors do this? Did you check taskfile?
Will have to try it out as they seem to just use the direct naming but they do support taskfiles per OS.
After merging #972 This feature is to simple and will cause confusion
Sometimes you really want some variables per environment.
It can be done with activation script, but I personally don't like having to add 2 extra scripts (.sh and .bat) to the repo just for that. Could also need more scripts in case of multi-environments. It's much nicer to be able to keep that in the pixi.toml file.
I currently use the variables per task but when you have several tasks using the same variable(s), it becomes quite verbose. And you might want a variable to be set without defining a specific task. I think having the same feature as variable per task but per env would be a nice addition. I also really like that those are default you can overwrite from the shell.
He @beenje, Thanks for the input. I completely agree with you. Still need to get back to this PR to test the above discussed change.