Fisher: `fisher up` wipes `fishfile` of all items that haven't already been installed

[neon64]

To reproduce:

$ fisher self-uninstall
$ curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs https://git.io/fisher
$ echo "stark" >> .config/fish/fishfile

Then run: fisher up in another shell.
On my machine, I received the following output - no acknowledgment of my existing fishfile whatsoever.

$ fish - c "fisher up"
OK fisherman is up to date
Done in 753ms
$ cat .config/fish/fishfile

Expected behaviour: fisher up would install plugins that haven't been installed yet, and update those that have.

Actual behaviour: fisher up only updates plugins that have already been updated, and removes all other plugins from the fishfile. (Thankfully I have it tracked in my dotfiles repo)

[neon64]

In addition: some plugins (eg: my own fork of clearance) don't seem to ever stay in my fishfile (after if I run fisher). The theme doesn't even install at all - I'm left with the default prompt.

EDIT: it appears that this second issue occurs because I set the universal variable fisher_active_prompt in my ~/.config/fish/config.fish. Is there a better way then to ensure that I will always use that prompt on different machines?

[bryaan]

I just ran into this issue and it seems pretty serious. I am not using GNU stow. My fishfile is simply symlinked from my dotfiles repo. Whenever I run fisher up the fishfile is erased. Is there another place this stuff is being stored?

Linked?
https://github.com/fisherman/fisherman/issues/380#issuecomment-363592660

[jorgebucaran]

@neon64 I couldn't reproduce this.

@bryaan How did you run into it?

[bryaan]

@JorgeBucaran I produced it exactly as written. However, I am no longer experiencing it and am thinking I was on an older version. Unfortunately at this point it isn't possible for me to verify it was an older version, but you can mark my issue as closed.

[jorgebucaran]

Oh, this is the worst kind of bug, it fixes itself and now we'll (hopefully) never find out until...

[jorgebucaran]

it happens again, of course.

[norcalli]

For what it's worth, I'm getting this issue as well, but only on certain machines. My remote EC2 machine doesn't have the problem. My home computer doesn't have the problem, but my laptop does. And the funny thing is that all of them are running Arch, haha. I'll see if I can figure it out since I have a decent test case.

[adamkiss]

this happened to me right now as well;

@jorgebucaran As far as I can tell it happens here: https://github.com/fisherman/fisherman/blob/c32e1e215adb4aea556a35326d306a5c105a9fd7/fisher.fish#L389

I think this is how it happens:

• install fisher, e.g. via curl
• run only fisher up, no fisher

In that case, script gets to Line 389, ./config/fisherman is of course empty, so it wipes fishfile.

Edit: @neon64's original problem happens few lines later: fishfile isn't wiped, only replaced with whatever is already cloned in in $fisher_config/$config, and that is written into fishfile.

I think a good solution to this is to have fisher update call whatever fisher does first.

[jorgebucaran]

@neon64 @adamkiss @norcalli @bryaan I just released fisher/releases/tag/3.0.0~! 🎉

V3 implements a simpler, less error-prone package resolution algorithm and the fishfile is now correctly updated.

---

For more information see the new documentation.