Hello! I tried to do a quick search for an existing issue but wasn't able to find one; please refer me to one if able :)
The Problem
Installing a plugin
When installing a plugin, oftentimes I don't care about specific versions and simply do fisher install plugin/name. IIUC, this will install the latest version of the plugin from HEAD, which isn't necessarily the latest released version (e.g., this repo is currently on release v4.4.8 but there are commits at HEAD after it). I could get around this by specifying @v4.4.8 or @v4 for example, but as I said before I don't really care about specific versions. However this also means that from Fisher's point of view (and from my point of view), I don't know which version of a plugin I have installed.
Updating a plugin
Similarly, when updating an existing plugin, I could just run fisher update plugin/name, but I again don't know which version was previously installed and which version is being newly installed. I also have this habit (paranoia, perhaps) of checking the release notes of anything I'm updating, but since Fisher doesn't tell me the currently installed versions of plugins, there's no way for me to do this.
Request
Perhaps it would be simple enough to save the commit ID of HEAD when a plugin is installed / updated. That way if I so desire I can go diff in the repo from my installed version to the current HEAD (or released) version to make sure I'm not installing anything crazy into my shell. But I'm not sure if that information is available through the current fetch mechanism, which looks like it just takes the tarball of the entire repo.
So instead, I'm imagining an additional fetch that gets the commit ID or latest release tag to be saved with each plugin. Examples:
https://api.github.com/repos/$OWNER/$REPO/commits/HEAD has a "sha" field. Unfortunately no "tarball_url", but if we're using HEAD then we can stick with the /tarball/HEAD URL that is currently being used.https://api.github.com/repos/$OWNER/$REPO/releases/$TAG_NAME, where $TAG_NAME is latest or tags/$NAME, returns the requested release. There doesn't seem to be a commit ID here, but "tag_name" could be saved. (Maybe there's some way to get the commit ID of the tag, but that would require at least another fetch...) This also has a "tarball_url" link.https://api.github.com/repos/$OWNER/$REPO/tags returns all the tags (some repos have tags but not GitHub releases); there doesn't seem to be a way to get the latest tag. So you could do a sort --version-sort -r on the "name" field, then use the "commit"."sha" field and the "tarball_url" field.
It would then be nice for the plugin versions to be shown along with fisher list, and potentially another subcommand that would check if a plugin has an available update (e.g., fisher update --check-only?).
Enhancements
There could also potentially be an option to fetch latest releases instead of from HEAD for people who don't care about specific versions but want to use released versions instead of whatever is currently on HEAD.
Also, if Fisher tracked plugin versions, it could skip the install step of plugins whose versions are already up-to-date, which might be nice too.
Hello! I tried to do a quick search for an existing issue but wasn't able to find one; please refer me to one if able :)
The Problem
Installing a plugin
When installing a plugin, oftentimes I don't care about specific versions and simply do
fisher install plugin/name. IIUC, this will install the latest version of the plugin fromHEAD, which isn't necessarily the latest released version (e.g., this repo is currently on release v4.4.8 but there are commits atHEADafter it). I could get around this by specifying@v4.4.8or@v4for example, but as I said before I don't really care about specific versions. However this also means that from Fisher's point of view (and from my point of view), I don't know which version of a plugin I have installed.Updating a plugin
Similarly, when updating an existing plugin, I could just run
fisher update plugin/name, but I again don't know which version was previously installed and which version is being newly installed. I also have this habit (paranoia, perhaps) of checking the release notes of anything I'm updating, but since Fisher doesn't tell me the currently installed versions of plugins, there's no way for me to do this.Request
Perhaps it would be simple enough to save the commit ID of
HEADwhen a plugin is installed / updated. That way if I so desire I can go diff in the repo from my installed version to the currentHEAD(or released) version to make sure I'm not installing anything crazy into my shell. But I'm not sure if that information is available through the current fetch mechanism, which looks like it just takes the tarball of the entire repo.So instead, I'm imagining an additional fetch that gets the commit ID or latest release tag to be saved with each plugin. Examples:
https://api.github.com/repos/$OWNER/$REPO/commits/HEADhas a"sha"field. Unfortunately no"tarball_url", but if we're usingHEADthen we can stick with the/tarball/HEADURL that is currently being used.https://api.github.com/repos/$OWNER/$REPO/releases/$TAG_NAME, where$TAG_NAMEislatestortags/$NAME, returns the requested release. There doesn't seem to be a commit ID here, but"tag_name"could be saved. (Maybe there's some way to get the commit ID of the tag, but that would require at least another fetch...) This also has a"tarball_url"link.https://api.github.com/repos/$OWNER/$REPO/tagsreturns all the tags (some repos have tags but not GitHub releases); there doesn't seem to be a way to get the latest tag. So you could do asort --version-sort -ron the"name"field, then use the"commit"."sha"field and the"tarball_url"field.It would then be nice for the plugin versions to be shown along with
fisher list, and potentially another subcommand that would check if a plugin has an available update (e.g.,fisher update --check-only?).Enhancements
There could also potentially be an option to fetch latest releases instead of from
HEADfor people who don't care about specific versions but want to use released versions instead of whatever is currently onHEAD.Also, if Fisher tracked plugin versions, it could skip the install step of plugins whose versions are already up-to-date, which might be nice too.