Fisher: Auto updater

[domoritz]

After reading https://medium.com/@robbyrussell/d-oh-my-zsh-af99ca54212c I think two simple additions could increase engagement. One is that when you update fisherman or a plugin, a short description of the changes (commit messages/ what files have changed) could be shown (#168). Second, fisherman could automatically update every other week to make sure that people stay up to date with the latest and greatest (this issue).

[ghost]

@domoritz Rather than adding this functionality right into Fisherman, I'd rather create a plugin that only users willing to let Fisherman update itself can run. What do you think?

[domoritz]

I think a lot of people will not update then. I think it would help to have an auto updater that updates even very infrequently.

[ghost]

What do @jethrokuan @orangecms @pickfire @herrbischoff @rolyreyes think?

I don't like the idea to update automatically, maybe just show a notification "there is an update available"?

What do other plugin/pkg managers do?

[domoritz]

I don't like the idea to update automatically, maybe just show a notification "there is an update available"?

Definitely. Never update without the user's consent. I was thinking about "There is an update available. Do you want to install it? [Y/n]"

[orangecms]

Updating Fisherman should only happen on the user's demand, preferably through their system's package manager (apt, pkg, zypper, portage, pacman, you name it) as they are used to that. Some systems provide auto-update functionality themselves, that's nothing we need to deal with. If a user installed to their home dir, then it should also be their own responsibility to keep it updated. A plugin could help here and be offered optionally during installation.

[domoritz]

Updating Fisherman should only happen on the user's demand, preferably through their system's package manager (apt, pkg, zypper, portage, pacman, you name it)

Then the preferred way should be to install fisherman through a package manager. Right now the recommended way to to run curl -sL get.fisherman.sh | fish. Also, how would that work on OSX (brew?) and Windows?

[orangecms]

Yes, the system's package manager should always be preferred. OSX has Homebrew, and for Windows there is apt-cyg. The only thing is that people need to write the packages. But basically these are more trustworthy and reliable than piping curl into a shell. Most ecosystems have package signing and report issues back to upstream.

[herrbischoff]

I think a lot of people will not update then.

What's the issue with that? Just because you (or anyone) feels that everyone should use the latest version, does not automatically make it the right approach for everybody. Certainly this is no reason to annoy people into updating. Besides, we're talking about shell-savvy people here, not mainstream customers who are getting notified to update to the latest iOS — and even that is a one-time affair, despite the looming badge many still don't update right away, although eventually. On a very personal note: I downright despise being patronized by software respectively its author(s).

I agree that an official Homebrew package may be beneficial although that needs to be updated for every release and will do very little besides running the install script. Another point of irritation (for me at least) would be installing a framework via a package manager.

Yes, the system's package manager should always be preferred. OSX has Homebrew, and for Windows there is apt-cyg. The only thing is that people need to write the packages.

Should this point to using the Homebrew infrastructure to install not only Fisherman but also its plugins, I'm strongly against it. This would be overkill, besides that fact that you would need to have a separate tap that in turn would be under the control of the Homebrew team. This effectively means giving away the plugin management and therefore all decisions about what gets included. Not to speak of the added burden of creating a Ruby-based formula to install a shell extension. I don't think this is reasonable.

[pickfire]

@bucaran, I don't support auto update. The update process is fast currently and can run in parallel. The user can just use a timer to set auto update.

[orangecms]

@herrbischoff If Homebrew is that weird and complicated, that's a fair point. I thought it was more evolved. The benefit would be a clean home dir and install/uninstall procedure without (what package managers have been invented for anyway), which is why I created the AUR package, done easily. I also write packages for portage (Gentoo's port/package manager), which is also straightforward. Is it really that hard with Homebrew?

[jethrokuan]

I think auto updating can come as a plug in, so it's something users can
opt in to have. It's not something I'd use personally either.
On 30 Mar 2016 3:23 pm, "Daniel Maslowski" [email protected] wrote:

@herrbischoff https://github.com/herrbischoff If Homebrew is that weird
and complicated, that's a fair point. I thought it was more evolved. The
benefit would be a clean home dir and install/uninstall procedure without
(what package managers have been invented for anyway), which is why I
created the AUR package, done easily. I also write packages for portage
(Gentoo's port/package manager), which is also straightforward. Is it
really that hard with Homebrew?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fisherman/fisherman/issues/169#issuecomment-203286509

[herrbischoff]

@orangecms: Here's the installation formula for fish for comparison. It's not exactly hard since you run brew create <URL> and get a template. It's just that updating this every time you make a small edit and would need to release a new minor version adds significant overhead. Plus, the pull request has to be made to the Homebrew repository for each change. While it is possible to have HEAD-only formula, those are not updated automatically when running brew update --all and need to be updated manually through brew reinstall --HEAD <formula>.

I support auto updating as a plugin, should anyone feel the need to actually create it. I wouldn't use it though.

[ghost]

Thanks @herrbischoff.

As a plugin, i.e, an official "plugin" that would be accepted into the index yada yada yada, it would not bother me at all, so if anyone wants to take a shot at it, ping me directly on the Slack channel and I'll gladly help out the best I can.

Now, as a core feature, I vote :-1:

[orangecms]

@herrbischoff That looks just as easy as I expected, so with the proper Makefile that would be possible with fisherman as well. It's by design that software hits repos after the package maintainers' review, so if users really want to update from HEAD (where a package maintainer cannot be blamed) it becomes the user's own responsibility when something breaks, which is exactly the same as when they use the shell script. So if we just provide a proper Makefile, the Homebrew formula wouldn't need any maintenance at all (that'd be the same for any package manager actually). Users always benefit from a clean installation state.
So writing an updater would just mean extra work (though basically git fetch/merge etc., which again might fail if users do stuff with the cloned repo, move it, or whatever). As a plus, dependencies can be dealt with properly, like git currently (where the user would in case of an outdated version just see a hint and maybe be pissed), or fish later when the conf.d feature hits the next release and we want to support it. They'd want/need an older/fixed version of Fisherman then in case they don't want to/cannot upgrade fish for whatever reason (it might cause other stuff to break, or depend on the sysadmin's/organization's policies etc.).

[kelvincobanaj]

I think that just showing a notification would be the best approach, since it doesn't disturb user and they can update when ever they feel like.

[herrbischoff]

Even so, I feel the notification should not be run automatically. To make that configurable and stay within the fish philosophy, it should be an optional plugin, as we already seem to have agreed on.

[ghost]

Alright, thanks @domoritz for bringing this up and thanks everyone for their comments.

Closing as this feature won't be implemented in the core.