Fisher: 👍👎 Vote: fisherman v3?

[ghost]

fisherman v3

Goals for the next major release:

• Require fish 2.3?
• Self-update by default after 3.
• Upgrading to fisherman 3 should not break anyone's system.
  

  2.3 should include a temporary 2.2 shim or ask the user to upgrade to 2.3?

• Internally, fisherman 3 should use a cache/config directory layout similar to fin to prevent name collisions.
  
  
  
  • ~/.config/fisher/USER/REPO (instead of ~/.config/fish/REPO)
  
  
  • Notice fisher instead of fisherman. Using the same name is impossible due to fisherman's current directory layout incompatible with the proposed alternative.
  
  
• Use a simpler single number release version scheme, similar to fin's 1, 2, etc.
• Emulate fin's fishfile handling:
  
  
  
  • Auto-formatting. For example, enforce user/repo[@tag] style, auto-sort, whitespace trim, comment sorting, etc.
  
  
  • The fishfile should be a mirror of the config. For example, removing items and running $fisher_cmd_name should remove installed items. The opposite is already true in current fisherman. #292
  
  
  • The fishfile should not list dependencies installed by other plugins.
  
  
• Be silent by default please (maybe only show the spinner?).
• Installing should always try to fetch a new copy of the plugin even if one already exists in the cache. The purpose of the cache should be similar to fin's, i.e, use as a fallback if there is no network.
• fisher ls is useless. If the fishfile _is_ a mirror of your config, you don't need and list command.
• Drop dep ref counting. Instead, update the config from scratch every time a new item is installed or removed.
• Create hardlinks of a plugin's exported functions/completions inside $fish_path, instead of soft links (also like fin). See #305.
• Do not automatically call set_color_custom (fisherman extension used by some themes).

[ghost]

Updated @fisherman/all

[kopischke]

Be silent by default please (maybe only show the spinner?).

Ugh, no, please don’t. Installing a plugin is a conscious decision to modify my system, I for one want to know what happens when I do without having to remember adding a flag. If default behaviour is contentious, it might make sense to add a fisher.config or similar to store default flags.

fisher ls is useless. If the fishfile is a mirror of your config, you don't need and list command.

Couldn’t disagree more: I don’t want to cat some file buried in an obscure config dir to know what is installed – especially when dependencies are not listed in it! I understand the fishfile based usage case, but fisherman’s strength, to me, is that it supports plugin management as a CLI, like brew or rbenv plugin.

[daenney]

Notice fisher instead of fisherman. Using the same name is impossible due to fisherman's current directory layout incompatible with the proposed alternative.

But we're upgrading, so why does that matter? At upgrade time you can move the contents of the old fisherman directory out and put new stuff in. There shouldn't be anything in there that isn't managed by Fisherman. If there is then the human violated the contract and it's their problem to fix.

Use a simpler single number release version scheme, similar to fin's 1, 2, etc.

I'm not sure that's such a great idea, what happens when you need to do a simple bugfix? Do you then release version 4? Major version numbers to a lot of people imply major changes under the hood, an upgrade they might be a bit more hesitant to make.

[ghost]

@kopischke TBH I am not sure what info or how to display it. I feel the current install/update log is rather naive and it has changed numerous times since 0.1.

Fetch xxx url
Pulled 1 new commit/s xxx

Pulled what commits? But then the problem is where do we cross the line of how much we show? Should I write a mini git diff in fish? To make it silent by default is my way of saying: I don't know what to do, so instead of doing it poorly, I'll show nothing, _Rule of Silence_: When a program has nothing surprising to say, it should say nothing.

A -verbse flag could force fisherman to spit a lot of information, like actually what's happening, git? curl, etc. Now, nothing is decided, and this bullet point is not as relevant as many of the other stuff I wrote above, so we can bikeshed over this one a bit later :)

[ghost]

@daenney At upgrade time you can move the contents of the old fisherman directory out and put new stuff in.

Ah, you mean after the upgrade? Like adding some temporary code that will fix the directories?

[kopischke]

@brj I’m perfectly fine with the current level of detail: what is fetched and roughly how much has changed, which I find far more useful than either nothing or every single curl request, but yeah, let’s bikeshed later. I am far more worried by the intended move from a CLI centred approach to a fishfile based approach the dropping of ls implies.

[daenney]

@brj Not even after the upgrade, during. If you detect that a fisherman/ exists just move it out of the way first and then pretend you're installing.

[ghost]

Not even after the upgrade, during. If you detect that there exists a fisherman/ just move it out first and then pretend you're installing.

Ah, I see. This makes sense. How long do you think is long enough before removing that code from the source?

[daenney]

I would say the next major release 😄. Most software doesn't support upgrading across multiple major release boundaries in one go.

[ghost]

@daenney Haha, but that will break things for slow-adopters.

Using a different directory name has no weak points, other than creating another directory. It's much simpler to advise users to delete the old fisherman dir and be done with it.

[daenney]

That depends, hence my comment on maybe not using a single digit version number but at least having a X.Y version scheme where we can fold in updates and other things that don't really warrant a major version boundary.

And it does have weak points, it is confusing. Why is Fisherman using .config/fisher, it's disconnected?

[kopischke]

Use a simpler single number release version scheme, similar to fin's 1, 2, etc.

That path leads to version numbers like Chrome 98 and Facebook.app 56 (iOS version numbering scheme) which, besides being rather silly, make it impossible to see which version changes are incompatible (normally denoted by the major number) and which are not (normally denoted by the minor number). Please let us keep using semantic version-ish numbering!

[ghost]

I prefer fisherman too, obviously. I just don't want to break stuff for future users. Let me see, maybe doing like you say is just one or two lines, so it's alright to keep it in the source for a few releases.

[daenney]

For future releases you could go as far to have a layout along the lines of .config/fisherman/<maj_version>/... which would ease upgrades.

[ghost]

As for the version number, I think the Major.minor.patch scheme is great when you have tools that can enforce the rules to be applied. There is nothing like that here, and it's a lot of work to keep up with that. Alas, this is another point I am after all ambivalent. If people don't like single version numbers, maybe X.y then.

[ghost]

@daenney Oh, that's funny, in an interesting way. I don't think I'll follow that path tho (but that scheme would be great for a more complex tool).

I am really looking for a way to simplify my future work in the project and make things much simpler, elegant and easier to maintain in the long run.

[daenney]

It's not just about what tools enforce, it's what users have come to expect too. In most cases major version boundary = major (breaking) changes. Browsers and some mobile apps eschew that but most software releases still follow this practice. If fixing a typo in Fisherman 4 results in the release of Fisherman 5 that's going to get weird fast.

[ghost]

@kopischke Couldn’t disagree more: I don’t want to cat some file buried in an obscure config dir to know what is installed. I understand the fishfile based usage case, but fisherman’s strength, to me, is that it supports a CLI based one, like brew or rbenv plugin.

A-ha. The problem with this one is that fisher ls may seem trivial, but it's _not_. What about people that create plugins like owner/fish-theme-ridiculous-name? Currently fisherman has __fisher_name that is in charge of guessing a plugin's name from its URL. This is really difficult to deal with, always subject to change and a PITA to maintain. It's a lot of code.

Another example, what about owner/fisher-plugin-foo? In this case, how do we know which is the main function exported by this file without sourcing all _.fish_ files inside the plugin's directory? It also means, we need to know when to choose to filter names and when not. It's a lot of complexity.

[orangecms]

It would make sense to be able to list packages without having to know about fishfile, so why remove fisher ls?
Why change structures again? People will be annoyed when upgrading again and have trouble etc. Someone recently complained about the 1 -> 2 migration script gone missing btw. What are your plans for migrations this time?
fish 2.3 is not yet available for everyone. I would give people some time or do a freeze for them.

[daenney]

A-ha. The problem with this one is that fisher ls may seem trivial, but it's not. What about people that create plugins like owner/fish-theme-ridiculous-name? Currently fisherman has __fisher_name that is in charge of guessing a plugin's name from its URL. This is really difficult to deal with, always subject to change and a PITA to maintain. It's a lot of code.

Another example, what about owner/fisher-plugin-foo? In this case, how do we know which is the main function exported by this file without sourcing all .fish files inside the plugin's directory? It also means, we need to know when to choose to filter names and when not. It's a lot of complexity.

Why not ask plugins to ship with a plugin.metadata file that has things like the plugin name, author etc. correctly encoded? Most systems have some form of metadata encoded, the gemspec in Ruby, setup.py for Python, NodeJS has their thing and so on. It's not a bad model. Heck you could require plugins to set a plugin_name somewhere in the files it ships that you can parse, and a version preferably too. If it's not there you can do some best-effort guessing.

[ghost]

@daenney Yeah, but fisherman is not a browser or a gigantic app. In fact, I am trying to make it simple. If I manage to get 3 through, I seriously expect almost no upgrades after that in a long time. As the current fin model is seriously indestructible. Less is more.

fish 2.3 is not yet available for everyone. I would give people some time or do a freeze for them.

True. I'll provide a shim for every place where I use a fish 2.3 feaure in the source. That's not so hard to do and I can do it.

[daenney]

I seriously expect almost no upgrades after that in a long time. As the current fin model is seriously indestructible.

Famous last words 😄. I'll hold you to that 😉.

[ghost]

Why not ask plugins to ship with a plugin.metadata file that has things like the plugin name, author etc. correctly encoded?

Hmm, is this complexity really worth it? I'd rather lower the bar, and encourage simpler plugins. After all, no one is really creating a lot of plugins. The plugin:ration is like 1:5 or worse. Most plugins useful plugins are stuff that do things only fish can provide, and those are very few.

[ghost]

@orangecms

It would make sense to be able to list packages without having to know about fishfile, so why remove fisher ls?

Because which way is the correct way:

1. Show everything inside the configuration, including dependencies. Also show who depends on what.
2. Show only those plugins the users has installed themselves.

Other things to take in account:

• Symbolic links.
• Should we show the names in their original form or translate the names using the rules in __fisher_name? Even someone once complained they didn't expect fisherman to filter out stuff like fish- or plugin-.

On the other hand, if you make the fishfile the center, all ambiguities cease to exist.

[daenney]

Hmm, is this complexity really worth it? I'd rather lower the bar, and encourage simpler plugins.

But this wasn't about simple polygons, this was about removing complex and hard to maintain code in Fisherman that tries to guess this instead.

Considering that you say yourself there aren't that many plugins being created and a lot of them live in the fisherman org adding a file like that would be trivial.

[ghost]

I can't justify some plugins having a fishfile to declare deps and now also a config.meta.

What I believe you are saying, is to drop the fishfile entirely and introduce a new configuration file for plugins. Sure, this would be nice. Also writing the yaml or json parser in fish.

I was considering writing a new plugin manager in another language, and I still might do it for fun, but there is an issue with that too.

The binary would run in a fish child process, so modifying the environment in the current session is not possible. Being able to modify the env is why having the plugin manager in fish makes sense and the reason why I still haven't used another language for this whole thing. (I'm not a fish masochist haha).

[kopischke]

Less is more.

I disagree: in this case, less is less. If less is what you are after, there is _fin_. I don’t want to sound adversarial, but turning _fisherman_ into _fin_ is a serious breach of the implicit user contract of _fisherman_. If lower maintenance overhead is what you are after, why not share the load of maintaining the more complex tool? I’d gladly volunteer!

[ghost]

@kopischke Haha you are more than invited to volunteer! Everyone in the team is a maintainer AFIK :)

[ghost]

FYI _fisherman_ vs _fin_.

• fisherman 2500 loc
• fin 250 loc

| Feature | fin | fisherman |
| --- | --- | --- |
| Support Wahoo / OMF / Tackle plugins and modules | No | Yes |
| Support uninstall hooks | No | Yes |
| set_color_custom | No | Yes |
| fish_user_key_bindings parser | No | Yes |
| Customize command name fisher_cmd_name | No | Yes |
| Install / Update / Remove plugins via CLI | No | Yes |
| List installed plugins | No | Yes |
| List / Tab-complete remote plugins (OMF, fisherman, etc.) | No | Yes |
| Customize output format with ls-remote --format="..." | No | Yes |
| Self-uninstall | No | Yes |
| Include custom script files in plugin (awk, py, etc.) | No | Yes |
| Install GitHub Gists | No | Yes |
| Install local (file system) directories as plugins | Yes | Yes |
| Support fish-shell 2.2 | No | Yes |
| Support OMF dependency plugins (parse bundle file) | No | Yes |
| Built-in man page | No | Yes |
| Use git | No | Yes |
| Use tar.bz archives | Yes | No |
| Fetch plugins by tagged [email protected] version | Yes | Yes |
| Fetch plugins concurrently | Yes | Yes |
| Manage nested dependencies recursively | Yes | Yes |

[kopischke]

@brj I am aware of the feature limitations of _fin_, but even at feature parity I would not use it as long as its interface is the fishfile

Personal opinion ahead: text file based user facing system management is a show stopping anti-feature (note “user facing”: it’s fine in sysops, devops and plain dev contexts!); one of the reasons I ended using _fish_ is it has less of that silliness.

I understand the appeal of a simpler code base (I maintain a few Vim plugins, so believe me: I really do), but “simpler code” is not a feature to users.

[ghost]

@fisherman/all @everyone

📣 Introduce a simpler fisherman v3

Please vote thumbs 👍 👎 if you like/dislike the proposal.

To me, a simpler fisherman means a better legacy for future fish users that will undoubtedly stumble upon this project at some point. A simpler fisherman means we are less disruptive to fish-shell in general. The current fisherman provides a lot of interesting extensions to fish-shell, but I would honestly prefer a more basic experience nowadays, without losing the power of plugins and complex dependency resolution.

If this proposal is rejected, nothing happens and I'll continue to provide support fisherman in its current form obviously.

[ghost]

@kopischke If the only problem you are having with my proposal is the lack of a CLI, that's a non-issue since I can make @3 work just as well with the commands you are used to install and rm (update would go away since fisherman would always update regardless tho).

Basically, install would just append 1 or more items to the fishfile and then the main loop would execute as if the user changed the fishfile. The same for rm. Some code to check whether the given item exists in the fishfile would be necessary, but that's not a lot.

I would really need some help to come up with the usage and help text output. I am not that good at writing those :0

[kopischke]

update would go away since fisherman would always update regardless tho

What would trigger such an update, assuming a stable set of plugins?

[ghost]

So, when you run fisher, it self-updates automatically. It also fetches plugins again, so there is no need to update plugins ever. And if the plugin can't be retrieved for some reason (bad network) it uses the cache if a copy exists in it.

[ghost]

Hi @fabio-flubit

[laughedelic]

Probably I'm missing something, but that branch looks just like fin 😐

Regarding the interface I completely agree with @kopischke:

• Current output is informative and useful. It can be probably improved, but I vote against removing it or hiding under the --verbose flag.
• ls command is useful, even if it will just list (+maybe format) the fishfile

Regarding versioning, I agree with @brj about misusing _semantic versioning_, but I think that one number scheme is not nice and informative at all. I would suggest to use date-based version (like 3.2016-06-03) or git describe-based (like 3.0-42-2f0a464) or a mix of the two.

About plugin names: why not just leave the owner/repo names as they are? I think it's better just to suggest some naming guidelines.

I think that this proposal looks kind of too monolithic, mixing independent things. Why not to make voting for each essential major change? Like create an issue and add a comment per each proposed change, then people vote with reactions on each comment.

[ghost]

Why not to make voting for each essential major change? Like create an issue and add a comment per each proposed change, then people vote with reactions on each comment.

To be honest, the answer is I don't like moving slow haha. If people are okay with the current way things are, then by all means, let's close this and keep fisherman as it is :)

[laughedelic]

This looks to me more like "all or nothing" 😆

[ghost]

If you look at the table above, there are like 20 items listed there. Are you suggesting to create ~20 issues? Lol.

[laughedelic]

Nope, I wrote something different: one issue and a comment per proposed change. Also, I thought we are considering the proposal from the original post, not the fisherman vs. fin comparison.

[ghost]

Ah, yeah, that too.

[ghost]

Haha seems like v3's proposal was not very popular.

[ghost]

@fisherman/all If the issue is losing the CLI, we can keep the CLI and still use fin's leaner model.

One more thing problematic with fisherman's current model is that there's a bug in the dep ref count, which was driving me crazy, fixed in fin btw.

[FabioAntunes]

@brj Sorry @fabio-flubit is my github company profile, sometimes I do forget that I'm logged in with that.

As for the proposal I thing we are being to drastic in here it's either too much complex or too much simple. Can't we find a mid term? I understand that complexity makes things harder to maintain and to make future changes without breaking existing functionality.

I believe that we should agree what is the core of fisherman and I don't think it's fair to lure users to switch from OMF and now tell them that most the functionalities will be removed.

I don't know if this is possible, but how about fisherman, run on top of fin. So it will be something like fin but with steroids, making the base code common between them, reducing maintenance?

[kopischke]

I believe that we should agree what is the core of fisherman and I don't think it's fair to lure users to switch from OMF and now tell them that most the functionalities will be removed.

Agreed.

[kopischke]

one issue and a comment per proposed change

I suggested something similar on Slack. Let’s address separate issues separately.

[ghost]

I think the new fin model is superior, both in implementation and simplicity. In 1/10 of the code, we get fisherman's best. So, I have no regrets for suggesting this change. Even if the trend would change now, I don't want to disappoint the people in this thread, so I'll just close this now and keep things the way they are.

Cheers!:)

[gretel]

@brj i'm confused what cli actually means - i wonder how i'd install a theme without one, clear my fog please.

[ghost]

As you know, CLI stands for command line interface.

fisherman has a rich CLI, that is, it provides named commands to let you accomplish different tasks:

fisher i user/repo

or if the theme is in the fisherman org:

fisher i THEME_NAME

In fact you can drop the i, as it's implied.

In contrast, the fin model _lacks_ a CLI. This is clearly on purpose.

To install (update is implied since we always fetched anew) and remove plugins you edit $fish_path/fishfile to add or remove entries such as owner/repo.

vim $fish_path

~/my/plugin
fisherman/nitro
oh-my-fish/plugin-thefuck
# commented/plugin

The reason it lacks a CLI is because it's not needed due to the configuration being erased and re-instantiated from scratch every time you run fin (despite of how slow that may sound, it's faster than fisherman installing the same from scratch, but slower when fisherman pulls from the cache obviously).

fin does this "re-instantiation" simply by looking at $fish_path/fishfile (where $fish_path is ~/.config/fish by default), so it essentially mirrors the fishfile.

Both fisherman and fin fetch in parallel and use a cache (although the cache is used differently, in fisherman it serves as a way to quickly install plugins if they have been downloaded at least once, in other words, you still need to update them even after you install them, as new copy will not be fetched automatically. In fin, the cache is used only as a fallback in case the network fails, so we always try to fetch a new copy).

[gretel]

ah, because i have not used fin yet i was unaware of it's file-based configuration - which oposses the cli approach if i get you right.
how about having no cli but allow to add a simple (maybe even backwards-compatible one) as a plugin?

[ghost]

how about having no cli but allow to add a simple (maybe even backwards-compatible one) as a plugin?

Like I explained above, fin has no CLI, but it's actually compatible with "most" fisherman plugins and even many oh-my-fish ones (except for those doing the init event hacks and stuff like we used to do in Wahoo), for example themes and plugins that only have one or more functions.

[gretel]

sure. i'm saying that a proposed v3 could have no cli. still, user could decide to add one and install it as a plugin (which is not authored yet but guess could be revised from the current code).

[ghost]

The proposed v3 has _no_ CLI, so it'd be essentially a retouched fin. As you can see by reading this thread, a lot of people opposed the idea of making fisherman more like fin, so I decided to drop the proposal and leave things how they are.

fisherman and fin can coexist independently.

[ghost]

still, user could decide to add one and install it as a pluing (which is not authored yet but guess could be revised from the current code).

Similar to what @FabioAntunes was proposing. I think this might be more confusing to new users.

[gretel]

@brj not sure if we match on thoughts. i've been reading over and also got the impression that it's about the cli. so i was thinking about a compromise, like a third approach, that would also well-exist with it's predecessors:

• fisherman as is (v2)
  
  
  
  • might move to a branch as discussed yesterday
  
  
• fin as is
• fisherman v3
  
  
  
  • has no cli, like fin
  
  
  • offers installation of a plugin (by adding a line to a configuration file) to provide v2-like cli
  
  
  • so for users requiring a cli (reflecting the actual features, not the one that should have gone to looese weight) that is a possible option instead of a reason to stay on fish v2.
  
  

[FabioAntunes]

• fisherman v3
  
  
  
  • has no cli, like fin
  
  
  • offers installation of a plugin (by adding a line to a configuration file)
  
  
  • so for users requiring a cli (reflecting the actual features, not the one that should have gone to looese weight) that is a possible option a not a reason to stay on fish v2.
  
  

What's the point of that? I don't see the point of having fin and try to make fisherman more like fin, you either have both the way they are, or just go for one. Having fisherman without cli and adding a plugin for me is the same has having fin and add a plugin.

Like I said if that's the point, just make fisherman v3 based on fin, something like:

fisherman v3 = fin + plugins

[ghost]

I suspect this would alienate some users, as they might feel relegated or second class citizens. Essentially, fisherman 3 would work out perfect for me out of the box, "but if you really feel you need your cli go install it". I can't do that, but...

what I would do instead is, what about this, write a CLI similar to current fisherman on top of fin's simple model. Basically some like:

• install or get PLUGINS // validated against fishfile
• rm PLUGINS // validated against fishfile
• update // self update
• list // pretty print contents of the fishfile
• help // show usage help
• version // show version

[gretel]

@FabioAntunes for me, the table posted clearly shows the differences between the two. i don't see why and how a cli as optional plugin that would not be installed by default would change that.
but i also don't feel like getting religious about details that in the end will result in some progression that we won't be able to foresee now.

[ghost]

Who is actually using fin here? or likes fin's model? Other than me, is there anyone who thinks fin is better or less is more? If most people prefer fisherman, we should leave fisherman the way it is.

But if some like fin and others like fisherman, then we can find that middle ground. Essentially, adding a CLI on top of fin and calling it fisherman 3.

[gretel]

well actually i was using wahoo that was kinda proposed to stay and now it's like v3 of it's successor 🔆

[ghost]

Haha, last time I check they are still 2.

[jethrokuan]

fin's model is similar to that of vundle, and I think it makes sense precisely because vi is a text-editing tool, so editing a text file to install stuff feel natural.

fisherman manages fish snippets, and because it's the command line, I think a CLI makes perfect sense.

[ghost]

@jethrokuan Hmm, haha that sounds like an unbeatable argument. You good debater bro?

[gretel]

following up on the truth of @jethrokuan - a tool that does manage fish files could work with and without a cli, right?
so why dont have it, optionally? i mean like how complex would that thing be, append/remove elements from text files?

[jethrokuan]

I'm just saying it doesn't make sense _not_ to have a CLI. Why would hopping into a text file and then running a command be simpler than just running an install/uninstall command?

Perhaps code-wise fin may be simpler, because there isn't the additional layer of abstraction, but I prefer this to that additional layer of indirection.

fin and fisherman serve two different audiences, and as a fan of the CLI for the CL I'm sticking with fisherman.

[gretel]

agreed. maybe i am paranoid, but i do care about the original author's motivation in regards to maintain support for therefore project - which currenly has - in opposition to his proposal - a cli. 📊

[ghost]

@jethrokuan's logic is gold.

I'll write a CLI on top of fin's model and propose a new 3 branch.

[ghost]

@gretel It's cool. @jethrokuan has a way with words and I am a very rule { action } oriented kinda person I was convinced as soon as I read his argument.

[ghost]

So, back to the plan, if we go on with fisherman 3 = fin + fisherman CLI, there are a few things that I'd like to remove or solve in a different way, such as uninstall hooks and key bindings.

[FabioAntunes]

Can some of that things be ported has plugins? I'm asking that because if we can provide a way of recreating fisherman v3 = fin + plugins = fisherman v2 that way we were able to have some support to users updating from v2 to v3 and reduce some migration problems. I would gladly try to help on that, might need some help though.

Unless the changes that you are trying to make, doesn't make any sense being ported to plugins

[kopischke]

there are a few things that I'd like to remove or solve in a different way, such as uninstall hooks and key bindings.

Please tell me you are not planning to remove either of them. I can understand, to a point, the annoyance with complex compatibility layers (OMF _et al_), but removing features that enable _fisherman_ to manage a plugin like _pisces_ is not what I would call a positive development.

[ghost]

Definitely possible. But after agreeing with @jethrokuan's point of view I am scratching my head now as to where this makes any sense at all.

[ghost]

@kopischke And ls-remote. That part is quite complex. Haha forget about it.

[FabioAntunes]

Well it makes sense in a way you are not creating a massive breaking change on fisherman, you are creating modular repos which makes code simpler and probably easier to receive contributions from other developers. Another thing is that you are not removing features/functionalities, the worst thing someone can do to a user is removing functionalities that he is used to.

I'm just giving my opinion I don't know if this is doable or even worth it, @brj you are way more into the project you will always have the last call

[ghost]

I'll try to simplify fisherman directly from fisherman's source to improve future maintenance, and keep fin alive and healthy too. Maybe in a distant future...