joinEnv - Just like joinPath but with ; for windows else :
Description
Title basically says it all. Once it's possible to prepend paths to the PATH via env (ideally fixed in https://github.com/go-task/task/issues/2034) , it should have a native cross-platform syntax for doing it cleanly on windows or posix platforms.
env:
PATH: "{{joinEnv "{{.TASKFILE_DIR}}/tools/bin" .PATH}}"
or perhaps
env:
BIN_DIR: "{{joinPath {{.TASKFILE_DIR}} "tools" "bin"}}"
PATH: "{{joinEnv .BIN_DIR .PATH}}"
Additionally, or alternatively, add a special variable: PATHSEP for platform specific path separation in env vars.
env:
PATH: "{{{{.TASKFILE_DIR}}/tools/bin{{.PATHSEP}}{{.PATH}}"
This sounds like an easy one. Open for community pull requests.
Happy with this too. A couple of implementation notes:
- Separators
- Windows uses
; - Linux/MacOS use
:
- Windows uses
- I think there is no harm in a "join" function and a variable being added.
-
PATHSEPis highly ambiguous. Something likePATH_ENV_SEPARATOR- I prefer clarity over short names
-
_as a word separator in var names
- Same for
joinEnv. This should be something likejoinPathEnv- Same reasons for naming as the variable
- Naming lines up with the variable
- We don't actually have a
FILEPATH_SEPARATOR- This could be added for parity
- Add both to the templating reference docs under system variables.
Agh... there's a func in there defined as os() which breaks importing os.PathListSep. How you want me to deal with it? Rename os()/arch() to goos()/goarch() perhaps?
I'm interested in working on this issue. Could you provide more context about what you're looking for? Any additional details about requirements or constraints would be helpful.
I'm interested in working on this issue. Could you provide more context about what you're looking for? Any additional details about requirements or constraints would be helpful.
Thanks but the work is done. The implementation details were essentially obvious and confirmed by @andreynering and @pd93 . It's just a matter of them finding time to review and merge.
" Perhaps this PR is more effort than value."
From the last comment on the PR by the reviewer. Am I to understand the meaning of this is they don't agree that adding this functionality is worthwhile?
The two people who green lit it were maintainers, the person who made that comment was a contributor. I think maintainers haven't had time to review/approve/merge feature PRs in a few months. Main commit history just has chores and fixes and such.