Don't install into ~/fisherman by default about fisher HOT 21 CLOSED

Actually, Fisherman does not install to $HOME by default, it installs to your current directory by default. You can change this location by cd'ing into your desired install location and then install it or move the directory and modify $fisher_home to point to the new location as defined inside ~/.config/fish/config.fish, but I reckon this is not specified anywhere. 😅

The original method to install Fisherman was by git clone; and make so it was obvious Fisherman would install to the current directory, but since the new advertised method just runs a script, I think we should install Fisherman to $XDG_DATA_HOME/fisherman by default like you say.

from fisher.

Yes, good idea. fisherman is a global command (you can type fisher in any cd). This means that the install location should be the same regardless of the cd as well.

from fisher.

Starting from 0.5.0, install.fisherman.sh will retrieve a more sophisticated install script.

If you have any other setup feature requests or ideas, now it would be a great time to let me know 😄

from fisher.

Just putting a note here, but default for $XDG_DATA_HOME is $HOME/.local/share/ and I'd say that $HOME/.local/share/fisherman seems reasonable to follow XDG.

from fisher.

Link to the full spec: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

from fisher.

@etu @daenney Thanks folks! That's exactly the plan. I will be shipping this as soon as I am done with 0.5.0.

See also here.

from fisher.

I agree to install it in an hidden folder, $HOME/.local/share/fisherman looks good, but consider not all the people will have $XDG_DATA_HOME set. I discovered this variable reading this issue.

My use case was: ok, let's trust the author and install it from install.fisherman.sh, and I think that it should default to an hidden folder even if no variable was found.

from fisher.

Yep.

If they don't have XDG_DATA_HOME, which is very common (I don't have it set), we install to $HOME/.local/share/fisherman by default, else, we install to $XDG_DATA_HOME/fisherman.

from fisher.

@szhu @fibo @simnalamburt @daenney @etu Hi everyone, the new Fisherman installer is up and running. Comments or feedback welcome as usual.

⚓

from fisher.

I got this error, after removing fisher

gcasati@Beintoo ~> fisher install shellder
Installing >> shellder
source: Error encountered while sourcing file '/Users/gcasati/fisherman/completions/fisher.fish':
source: No such file or directory
Aye! 1 plugin/s installed in 1s

from fisher.

@fibo

0.5.0 was a huge update, and this is probably due to the changes in the internal API. For example, there is now a new $fisher_file and $fisher_prompt variables used to check what plugins are currently installed and I think that's the issue. I recommend a clean install from scratch.

If this was post 1.0 I would not recommend this, but since we are still 0.5.0 I think is natural to understand that the internal API is still not stable. Now, I don't expect any major API changes from now on, so this is probably the only time you would need to do this.

If you still have the same issue after that by all means create a new issue and we can troubleshoot that together 😅

from fisher.

no prob,

well, now if I start typing fisher install b everything blocks, maybe there is some issue with autocompletion?

from fisher.

That's odd, autocompletion should be working just fine.

Can you confirm that $fisher_file exists?

from fisher.

It seems like I found fisherman cache in ~/.config/fisherman/cache, is the correct? I thought it should be ~/.cache/fisherman?

from fisher.

That's correct, the cache is used internally by Fisherman and users should not delete it as we use it to store a copy of the index, key bindings, the fishfile, etc. Perhaps another name would be less confusing?

If what you want is storing your fishfile in a different location you can do so by setting fisher_file in your config.fish

set -g fisher_file there

from fisher.

@bucaran If it's used internaly and not supposed to be altered by the user. The proper location would be $XDG_DATA_DIR or $XDG_CACHE_DIR depending on the nature of the data.

If the nature makes startup or something slightly slower because it needs to recalculate something, it's a cache. If the user gets sad because her/his plugins doesn't load, it should be in XDG_DATA_DIR.

from fisher.

So, this "cache" is basically where repos get downloaded to. When you install a plugin, it is downloaded to this "cache" for the first time. When you uninstall a plugin it only gets removed from there if you use --force.

Install it again? Fisherman walks the plugin's path in the cache and moves file to the applicable directories inside $fisher_config. Uninstall, install, uninstall? Files are moved back and forth between $fisher_cache and $fisher_config.

Since Fisherman uses a "flat" tree by design, we can't simply add the paths to the downloaded repos to $fish_function_path which is what I did originally with Wahoo and Oh My Fish!

Why? Because it gets slow as you need to juggle more and more paths of the plugins you install not to mention the PITA of mutating that array as the user installs / uninstalls plugins. Like searching the array, finding the index of path, removing it, etc.

In Fisherman there is only one path added to the $fish_function_path, think of it as a huge Megazord plugin that is loaded only once, which is why Fisherman is as fast as a vanillar Fish installation.

Now, I also use the cache to store a copy of the index (plugin database), and your fishfile. Both the cache $fisher_cahe and the fishfile $fisher_file locations are configurable too.

I don't see the benefit of moving the cache outside $fisher_config by default, but if you think I am wrong please give me your arguments, and we'll change it. I am also learning here.

from fisher.

So, I'll just link this blog post: https://ploum.net/207-modify-your-application-to-use-xdg-folders/

At the moment, I'm not very deep into the inner functions of how fisherman works, or how the tools are built. Or even exactly what they do when you run different things.

At the moment, I'm looking at this from a user-perspective knowing how XDG is supposed to split up applications.

If I remove ~/.cache/ and start a new terminal with a fresh shell. Will it break? Will everything just work as before, but maybe slower on first load?

from fisher.

@etu I am afraid that break, it will.

If the naming is an issue, how do you feel about stage? Because that would not be so distant from the truth either.

from fisher.

@bucaran The naming isn't the issue, I think. Just the location, I believe. The article explains quite well the user-reaction on removal of each directory.

from fisher.

@etu Thanks for linking that up. It looks like a friendly read. I'll go over it and come back to this later.

EDIT: I'll keep this closed and open #72 to track this discussion.

from fisher.