Everything is available. Not just plugins, but anything that runs in "fish". Well, that's the promise and the pledge. This includes whatever is the OMF barracks, and also Wahoo <github.com/wa>. If you know anything for Tacklebox, that will run in Fisherman too.
I am working on some tutorials and getting everything ready for the next milestone 0.5.0, but better ways to discover and preview the ecosystem is in the works and I vow to make it awesome.
Since we're talking about shells, if you're using Emacs, you might be surprised to know that it comes with its very own shell, called Eshell. These days I use it almost exclusively.
So, to answer the most important question, WHY do I want this thing?
Long wall of text ahead, but I promise this covers a lot.
---
If you are only using fish, you are missing out the ability to effectively share plugins, prompts, configs, missing completions, documentation for external utilities, plain old scripts or bundle of scripts.
If you are using Oh My Fish (OMF) / Wahoo or Tacklebox, you may be already doing some of the above, just very poorly.
---
So, I want to create shell scripts, snippets or let's call them utilities that follow the [UNIX guidelines](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...) for option parsing, fish auto-completion out of the box, with bundled documentation using the traditional `man(1)` pages like a boss, and I want my scripts to come not only in the form of `.fish` files, but I want to ship them bundled with scripts in other languages too sometimes, maybe Awk or Perl, or if you are cool, Python. Then I want to commit that to a GitHub repository, or as a Gist, or to BitBucket, GitLabs or my own server if I want.
---
Fisherman makes this process very easy and it also gives me access to an external ["index"](https://github.com/fisherman/fisher-index) to where I can publish these utilities, let's better call them now plugins so that others can discover my stuff without having to know the URL in advance.
Fisherman is not like, say `brew` where you typically share one or more binaries, that's a true package manager indeed.
---
Fisherman, however, is about sharing snippets, prompts, configurations, initialization scripts, like I said above, that kind of stuff. In the Fisherman jargon, I am rolling all that into a bun and calling it "plugin".
---
To Fisherman they are all the same, they should be, and if that's not the case your "framework", "manager", whatever, is not doing you any service.
---
There are several different setups that Fisherman understands and can process. Why? Because there are already existing snippets and plugins with their own idiosyncrasies. The same ones I mentioned above. Also people creating stuff in fish and releasing it without a particular "framework" in mind.
---
Fisherman recognizes packages from all of those dimensions and lets you install them and use them as you wish. Without strange restrictions that these other "frameworks" often pose on you, like strange name conventions or strict URL forms. It _will even__ try to guess the URL and correct your mistakes sometimes.
---
You can also "install" stuff locally and it will symlink a directory to Fisherman's configuration directory so that you can develop, test and iterate :repeat: fast and without having to do anything but `(1)` creating a directory and `(2)` typing `fisher install .` or `fisher install <my_path>`. You can commit your changes to a Git repo and that will not affect the process. It just works™.
---
But also you get a builtin (obviously it's builtin) cache system to let you install stuff while you are offline (assuming you already downloaded the _stuff_ first) and that segues into Fisherman's simplest, but IMO best feature, the flat tree :evergreen_tree:.
Here is the thing, Fisherman is as fast as no* Fisherman.
7 comments
[ 2.8 ms ] story [ 27.7 ms ] threadI am working on some tutorials and getting everything ready for the next milestone 0.5.0, but better ways to discover and preview the ecosystem is in the works and I vow to make it awesome.
Long wall of text ahead, but I promise this covers a lot.
---
If you are only using fish, you are missing out the ability to effectively share plugins, prompts, configs, missing completions, documentation for external utilities, plain old scripts or bundle of scripts.
If you are using Oh My Fish (OMF) / Wahoo or Tacklebox, you may be already doing some of the above, just very poorly.
---
So, I want to create shell scripts, snippets or let's call them utilities that follow the [UNIX guidelines](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...) for option parsing, fish auto-completion out of the box, with bundled documentation using the traditional `man(1)` pages like a boss, and I want my scripts to come not only in the form of `.fish` files, but I want to ship them bundled with scripts in other languages too sometimes, maybe Awk or Perl, or if you are cool, Python. Then I want to commit that to a GitHub repository, or as a Gist, or to BitBucket, GitLabs or my own server if I want.
---
Fisherman makes this process very easy and it also gives me access to an external ["index"](https://github.com/fisherman/fisher-index) to where I can publish these utilities, let's better call them now plugins so that others can discover my stuff without having to know the URL in advance.
Fisherman is not like, say `brew` where you typically share one or more binaries, that's a true package manager indeed.
---
Fisherman, however, is about sharing snippets, prompts, configurations, initialization scripts, like I said above, that kind of stuff. In the Fisherman jargon, I am rolling all that into a bun and calling it "plugin".
---
To Fisherman they are all the same, they should be, and if that's not the case your "framework", "manager", whatever, is not doing you any service.
---
There are several different setups that Fisherman understands and can process. Why? Because there are already existing snippets and plugins with their own idiosyncrasies. The same ones I mentioned above. Also people creating stuff in fish and releasing it without a particular "framework" in mind.
---
Fisherman recognizes packages from all of those dimensions and lets you install them and use them as you wish. Without strange restrictions that these other "frameworks" often pose on you, like strange name conventions or strict URL forms. It _will even__ try to guess the URL and correct your mistakes sometimes.
---
You can also "install" stuff locally and it will symlink a directory to Fisherman's configuration directory so that you can develop, test and iterate :repeat: fast and without having to do anything but `(1)` creating a directory and `(2)` typing `fisher install .` or `fisher install <my_path>`. You can commit your changes to a Git repo and that will not affect the process. It just works™.
---
But also you get a builtin (obviously it's builtin) cache system to let you install stuff while you are offline (assuming you already downloaded the _stuff_ first) and that segues into Fisherman's simplest, but IMO best feature, the flat tree :evergreen_tree:.
Here is the thing, Fisherman is as fast as no* Fisherman.
The [initialization script](https://github.com/fisherman/fisherman/blob/master/config.fi...) basically declares a few variables and evaluates only config files that you allow F...