Added v

[corpix]

This is a uniform tool to manage toolchain versions. It manages only Go and Node.js versions at this time but, in theory, could be extended to manage any other language toolchain.
Goals of this tool are:

• to be simple "one file" solution
• which does not require any installation or modification of bash/zsh/*rc files
• written in pure Python 3 without any other dependencies than python and git binary

---

• github.com repo: https://github.com/corpix/v
• godoc.org: It have no godoc, tool is implemented in pure Python without dependencies
• goreportcard.com: None

Make sure that you've checked the boxes below before you submit PR:

Some items are unchecked because this is just utility, not Go package.

• I have added my package in alphabetical order
• I know that this package was not listed before
• I have added godoc link to the repo and to my pull request
• I have added coverage service link to the repo and to my pull request
• I have added goreportcard link to the repo and to my pull request
• I have read Contribution guidelines, maintainers note and Quality standard.

[cassiobotaro]

@avelino the tool is written in python, but can be useful in go, what you thing about it?

[avelino]

It doesn't look good to me

[corpix]

@avelino maybe you could show me what's wrong?

[kirillDanshin]

LBTM. we even didn't add travis/gimme. I think we don't need to add it too.

[corpix]

@kirillDanshin Could you please explain me why? «we even didn't add travis/gimme» sounds as unconstructive criticism to me.
I think this tool could be helpful for developers who use go to test the code with different versions of the toolchain. You have gvm in the list, so why not add a tool which has an alternative point of view on problems which gvm solves?

[geovanisouza92]

@corpix Why it's written in Python instead of Go?

[corpix]

@geovanisouza92 because:

1. it exists in almost every linux distribution
2. this tool is intended to be a solution which does not require a system with pre-installed go toolchain
3. I don't like an idea of "binary distribution" for the software because I don't trust other people and don't want others to trust me(python code is transparent and could be easily reviewed by community in contrast to binary release)

[crgimenes]

It does not look good to me either.
Consider rewriting in Go.

[corpix]

You don't like a tool just because it is not written in Go. Okay, I got the point.

[crgimenes]

Do not get me wrong, it seems like a great tool. But the list is about Go, not about Python. We could not revise the code, and apply the same pattern we applied to the other PRs, we would have to open many exceptions, it would not be fair to others.

[corpix]

Yes, this will be unfair. Well, rules are rules, this is ok.
But following this rule some tools which are already in list should be rejected because their repositories does not contain a Go code:

gobrew, gvm and rodent solves a similar set of problems v is trying to solve

• https://github.com/c9s/c6
• https://github.com/Mainflux/mainflux
• https://github.com/VividCortex/johnny-deps
• https://github.com/rjohnsondev/vim-compiler-go
• https://github.com/Microsoft/vscode-go
• https://github.com/skelterjohn/go-pkg-complete
• https://github.com/cryptojuice/gobrew
• https://github.com/moovweb/gvm
• https://github.com/alouche/rodent

[PotHix]

@corpix You're right on this one. There is an issue for almost the same purpose (#1446), please comment there about this.

Please provide separate PR's with your arguments to remove each of the libs mentioned. :)

[corpix]

@PotHix I don't support an idea to get rid of the things written in programming languages other than Go(because they could be useful for other people), so I won't, sorry :)

[PotHix]

No problem at all, I was just following your own argument: But following this rule some tools which are already in list should be rejected because their repositories does not contain a Go code. :)