Scoop
Scoop copied to clipboard
ScoopInstaller
feat(scoop-(un)hold): Support `scoop (un)hold scoop`
Description
Allow to disable scoop itself updates.
This configuration has the same function with scoop (un)hold scoop.
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:
- [x] I have read the Contributing Guide.
- [x] I have ensured that I am targeting the
developbranch. - [x] I have updated the documentation accordingly.
- [ ] I have updated the tests accordingly.
- [x] I have added an entry in the CHANGELOG.
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.
@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. 😥
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...
@niheaven
https://github.com/ScoopInstaller/Scoop/blob/66296dcad228198d1d8628007dad7c63b5850574/libexec/scoop-update.ps1#L62-L66
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. 😂
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.
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.
@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. 🤔
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.
@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. 🤔
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...
Or develop stuff in a separate repo and use it from the editor or create a custom shim that points to the develop repo. :smile:
@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?
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.
@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 All right, if you resolutely retain this opinion. Could we add a configuration of
SCOOP_HOLD_DAYSinstead 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!
@niheaven Some new change in https://github.com/ScoopInstaller/Scoop/pull/5089/commits/7f63df2cf7297017e723cc0f37611cf18f3a1fd4
I will update changelog soon
@niheaven I find a problem about it. I move the set_config, but it will set lastupdate every time if update bucket well.
When I update next time and have configuration about SCOOP_HOLD, it will refresh the lastupdate if I did scoop update in $SCOOP_HOLD days. It may cause disable update for long time more than $SCOOP_HOLD days.
@niheaven I find a problem about it. I move the
set_config, but it will setlastupdateevery time if update bucket well.When I update next time and have configuration about
SCOOP_HOLD, it will refresh thelastupdateif I didscoop updatein $SCOOP_HOLDdays. It may cause disable update for long time more than $SCOOP_HOLDdays.
Found a solution, but this may hold no more than 1 day. I'll make review soon.
For the latest change, I mainly refactored the code as @niheaven suggested. By handling many of the judgments in try-catch codes, the code became more streamlined. And New-TimeSpan makes it easier to compare times.
@niheaven @r15ch13 @rashil2000 Hope for your advice! 😊
The name update_until doesn't reflect what it actually does. 🤔
Also missing the description in scoop-config.ps1
@r15ch13
I think @niheaven wants to use this variable as a built-in variable, similar to lastUpdate that also does not appear in the config description, and the general user should only control it through scoop (un)hold scoop.
I think @niheaven wants to use this variable as a built-in variable, similar to
lastUpdatethat also does not appear in the config description, and the general user should only control it throughscoop (un)hold scoop.
Yes, it is, this should be controlled by scoop hold scoop only, or we met the case that any later update will extend the holding period.
@niheaven @r15ch13 @rashil2000 I think this feature is ready to be merged, are there other comments?