V: Add option to turn off v up command

[Jacalz]

Discussed in https://github.com/vlang/v/issues/2797 was the idea that distro packages of V should have the possibility to turn off the v up command and hide it in the help menu. This is due to the package maintainer managing the update of V and the user should thus not have the option to update it themselves.

[gslicer]

Another idea would be to still allow v up but then it would detect that the user has no access rights to the current v-executable in his path and just print the new release version available, something like:

Updating V...
From https://github.com/vlang/v
 * branch            master     -> FETCH_HEAD
 8c7f5d5..76cd70c  master     -> origin/master
Current release version: V 0.1.22 8c7f5d5 
Available release version: V 0.1.23 76cd70c
Cannot update managed V installation, please contact your administrator.

[Jacalz]

Currently it just errors that the folder it resides in isn't any git repository.
Your idea @gslicer is really good too, but I think that I would prefer to have it hidden altogether if it is possible.

[netmute]

One can always apply a patch that disables v up before building the binary. This should be pretty straightforward to automate for package maintainers in their build pipeline.

[spytheman]

Yes, all v up does is inside tools/vup.v . Package maintainers just need to replace this file with a dummy one that does for example:
```v
fn main(){
println('This is a managed v installation. Instead of v up, please use:')
println('apt update v')
}
````

[Jacalz]

Carrying patches on top of a package is never a good idea if it can easily be avoided. Having to rebase the patches takes a lot of time. The best way would be to have a flag in the make file. Makefiles does support command line options and that could be very useful.

[spytheman]

We are talking about plain file replacement, not patching or rebasing anything.

[spytheman]

And if you want to make your life as a package maintainer easier, just place the whole of v inside /opt/v . Do not try to disfigure it to pieces to your distro liking. Instead just put it in /opt/v/ and add a symlink for /opt/v/v to your /usr/bin/v or whatever name you want to call it. It works - I personally use it this way.

[elimisteve]

For security purposes it would be _great_ for V to support deterministic builds. This becomes harder if there are different V Linux x86_64 binaries floating around for each distro.

Could V inspect its environment to tell users how to update it? How about checking to see if some directory is writable, or check for update_command.txt, and if it's there, print its contents, and if it's not, allow v up to work as it does now?

[spytheman]

@elimisteve cmd/tools/vup.v is a separate program. Changing its source will not affect the main v binary executable. The relationship between the main v executable, cmd/tools/vup.v and cmd/tools/vup is that when you do v up, the main v executable checks the modification date of the source file cmd/tools/vup.v against cmd/tools/vup , and if vup.v is newer, it recompiles vup, then launches it.

[spytheman]

=> Changing the cmd/tools/vup.v to be a 3-4 line dummy program that just prints a message will not change the main v binary, so in my opinion has no relevance to determinism of v itself, nor to the determinism of programs transpiled by v.
In a way, you can think of cmd/tools/vup.v as your update_command.txt, it is just a .v source file, instead of a .txt text file, and each distro can change it to do whatever is relevant for the distro - it can even launch the distribution's native update mechanism.

[elimisteve]

@spytheman Great points, I didn't realize it was a separate binary 👍 . A different vup.v per distro sounds good.