Closed TheFriendlyCoder closed 1 year ago
Interesting, very interesting. @juev sensei, thoughts?
I need some time to think
Adding to .bashrc
to execute gobrew use mod
of #101 upon cd
.
Options below:
function cd {
builtin cd "$@" && ls go.mod 2> /dev/null && gobrew use mod"
}
or
alias cd='builtin cd "$@" && ls go.mod 2> /dev/null && gobrew use mod'
Golang is simple language. And all changes in language do not broke programs. All we need - use the last version golang for build.
These changes very interesting, but on my through not needed.
Thanks, yes I agree on that too. Generally only last 2 versions are EOL supported. I won't put that on the README, since it is not a feature the benefits using Go, and have the newly go use mod
in the shadows if someone wants to use it.
One benefit of this I can see is putting it in the CI matrix [latest, dev-latest, mod]
Environment managers from other toolchains, like pyenv for Python or SDKMAN for Java, support automatically changing the version of their respective runtimes based on a simple plain-text config file in the root folder of a project workspace (ie:
.pyenv
for Python,.skdmanrc
for Java). It would be nice if gobrew supported something similar.I think the way these other tools work is, they inject hooks / shims into the shell environment so that when a user performs a
cd
operation the tool will look in the target folder it is changing to and locates a file with a specific name. Then it parses the contents of that file, and performs the appropriate environment-switch operation / command to automatically set the runtime version to the value stored in the text file.Suggestion You could set up gobrew to with a similar shim, so that if a file named something like ".gobrew" exists in the folder the user is changing to, then it could parse the contents of that file and see if a GO runtime version is installed that matches the value stored in the file. If so, then it could trigger the same logic as is done by running the "gobrew use" command, substituting the value from the file for the version number.
The tool would also need to be smart enough to save the previously used GO version and restore that when the user changes out of that directory, so that the global state is restored.
In addition, the tool would need to be smart enough to detect when the user changes into a subdirectory where one of the parent dirs contains the ".gobrew" file, so that the environment doesn't switch back when the user is navigating subfolders in the same workspace / repository.
There may be one additional edge case here to consider. Unlike the way pyenv and sdkman work, I think that changing runtime environments using gobrew affects the global system, so if a new terminal session is open while navigating the file system that new terminal session would inherit the same GO version as the previously active session. Similarly, if someone were to change directories into a GO project workspace and then subsequently terminate their terminal session, any future terminal sessions that open would likely use the same GO version from that workspace rather than the default global version. So some additional functionality may need to be added to gobrew to distinguish between "temporary" GO versions, and the default / permanent one.