feat(scoop-(un)hold): Support scoop (un)hold scoop

[yi-Xu-0100]

Description

Support scoop (un)hold scoop.
Allow to disable scoop itself updates for one day.

Motivation and Context

The scoop is a app in scoop, but it can not to be hold.
Now it works. 😁

How Has This Been Tested?

Checklist:

• I have read the Contributing Guide.
• I have ensured that I am targeting the develop branch.
• I have updated the documentation accordingly.
• I have updated the tests accordingly.
• I have added an entry in the CHANGELOG.

[niheaven]

I don't think scoop itself should be hold (not updated) since we keep fixing bugs in it, and this shouldn't be fixed IMO.

[yi-Xu-0100]

@niheaven It is only an option both for user and contributor. Scoop always updates with remote without asking, and it may lose the local changes.🤔

For me, I change the content of scoop for doing some test locally, but the scoop always updates as the remote and loss my change content, I think I can hold the scoop to test the local feature, and enable update quickly if new version published. 😥

[niheaven]

Yes, I've the same trouble as yours, and I think a better way is auto stashing the uncommited changes and noticing users that they have these changes and scoop has stashed them.

Would you like to make this feature and submit PR about that?

'Cos indeed a config option to HOLD update of scoop is so easy to be forgotten...

[yi-Xu-0100]

@niheaven

Scoop/libexec/scoop-update.ps1

Lines 62 to 66 in 66296dc

	$SCOOP_HOLD = get_config 'SCOOP_HOLD' $true
	if($SCOOP_HOLD) {
	warn "'SCOOP_HOLD' has been setting to '`$true' and skip updating Scoop..."
	warn "If you want to update Scoop itself, use 'scoop config SCOOP_HOLD `$false' or 'scoop unhold scoop' to enable it."
	} else {

I use a warning notification when scoop used to update itself. It effects every time when users want to update scoop. 😁

The stash operation may helpful, but I may not deal with it good. If I make this feature, I will submit a PR to here. 🙌

But I also think the hold should be a choice for uses of scoop. The scoop is an app in scoop/apps, so I think it needs to obey the rule of an app. An app can be hold to disable update, not likes Windows. 😂

[r15ch13]

Wouldn't it be better to move the bucket update code out of update_scoop() so there is no need for a big overarching if-statement? The function can then be returned early.

[niheaven]

Just add autostash in #5091, and this could meet your need @yi-Xu-0100

[niheaven]

Wouldn't it be better to move the bucket update code out of update_scoop() so there is no need for a big overarching if-statement? The function can then be returned early.

Good idea for the function separation and may be done later.

[yi-Xu-0100]

@niheaven

#5091 is good for users who change a little and do things in the current branch. 👍

But for contributors, It always set the scoop to remote, we still need to check out our own branch and stash pop changes. It will make many steps for test. 🤔

[niheaven]

No, you don't. It will stash uncommitted change on your working branch and then checkout 'develop' branch (the one in config file), all your works will not be lost.

[yi-Xu-0100]

@niheaven I know that the #5091 will stash uncommitted change and will not lose my work. That is a good job! 👍

But we do not always work on the branch in which we config SCOOP_REPO and SCOOP_BRANCH in the config file.
New PR may create a new branch, and I do not want to set the config every time. 😥

It will update when I test in another branch, and I need to check out and get my work back every time. It can be simply used scoop hold scoop to avoid this happening. 🤔

[niheaven]

Hmm, you may not understand my point. Which I mean is, you create a new branch and do some change, commit them, then do another changes, then you want to test it but a scoop update happened, the #5091 will stash all your uncommitted changes on the new branch and then the following code of scoop update will checkout develop.

All you do after such update are checkout your working branch and git stash pop, everything is back: your new branch, your new commit and your uncommitted changes.

Keep coding forward, and you never need to test something that invoke scoop update except for scoop update itself, right? For the latter case, change your SCOOP_REPO and SCOOP_BRANCH...

[r15ch13]

Or develop stuff in a separate repo and use it from the editor or create a custom shim that points to the develop repo. 😄

[yi-Xu-0100]

@niheaven @r15ch13

I know what all you say, I just think it needs to do many steps to test little things about update.

The another reason is that I think the user can choose to hold the scoop if the user did not have a fork repo.
It could be an option, right?

[niheaven]

The another reason is that I think the user can choose to hold the scoop if the user did not have a fork repo.
It could be an option, right?

That's what I'm against, that one should never hold scoop core since there're ongoing bugfixes and one may omit them if scoop is held. It's something dangerous even if there may be enough notices or warnings.

[yi-Xu-0100]

@niheaven All right, if you resolutely retain this opinion. Could we add a configuration of SCOOP_HOLD_DAYS instead of it?

Just like windows, it could hold update operation for days. It could be a choice for the minority.

[niheaven]

@niheaven All right, if you resolutely retain this opinion. Could we add a configuration of SCOOP_HOLD_DAYS instead of it?

Just like windows, it could hold update operation for days. It could be a choice for the minority.

That's great, and please make it!

[yi-Xu-0100]

@niheaven The new configuration of SCOOP_HOLD_DAYS has been done. 😁

[niheaven]

Change the option name to SCOOP_HOLD and remove the option after holding days.

[yi-Xu-0100]

@niheaven @r15ch13 @rashil2000 I think this feature is ready to be merged, are there other comments?

[niheaven]

I'm fine expect for the try-catch (if-else IMO).

[rashil2000]

Looks fine to me

[r15ch13]

The update_until value still does exactly the opposite of it's name.

[niheaven]

So update_after? Or stop_update_until, hold_update_until.

[r15ch13]

hold_update_until sounds better. It also needs to be added to the description in scoop-config.ps1

[niheaven]

But this could not be set via scoop config, just likes lastupdate, since it is POSIX and is not human writable, in most cases.