fisher blocks GitHub Codespaces personalized dotfile setup

[vorburger]

I attempted to invoke Fisher in a bootstrap.sh for a GitHub Codespaces personalized dotfile setup.

This didn't work and blocked the GitHub Codespaces setup. I have debugged it and realized it's because of this line:

isatty || read --local --null --array stdin && set --append argv $stdin

This blocks and waits for input because during a GitHub Codespaces setup STDIN is set to an pipe. (I do not know why GitHub does this; I'll post on https://github.com/orgs/community/discussions/35527 and see if GitHub wants to provide a reason for why they do this.)

This technically isn't GitHub Codespaces specific, but would similarly block other non-interactive uses of fisher anywhere where STDIN is blocking.

I can work around this using fisher </dev/null, so I just wanted to let you know about it FYI. It seems weird to have to do this. (And took me some time to figure out.)

https://github.com/vorburger/dotfiles-reproduce-problem illustrates this.

[jorgebucaran]

I'm happy to change this. I just need a way ti grab stdin from the user for things like piping plugins into Fisher install, update and remove commands.

[vorburger]

need a way ti grab stdin from the user for things like piping plugins into Fisher install, update and remove commands.

right so just to understand the idea here is that one could do something like fisher <plugins.txt, with a file containing lines such as install jorgebucaran/nvm.fish and remove ... etc. am I understanding this correctly? (BTW that feature is not actually documented on the README.)

How about perhaps making this something triggered by an explicit flag, instead of implicit automagic?

So you would have to e.g. fisher --STDIN (or fisher -- or whatever). That seems better (to me).

[jorgebucaran]

That's correct. Introducing a flag would be a breaking change, though. I'm not really opposed to it, but could this be worked around on your end?

[jorgebucaran]

Otherwise,fisher -- could do it too. 😁

[vorburger]

could this be worked around on your end?

GitHub Codespaces specific, but would similarly block other non-interactive uses of fisher anywhere where STDIN is blocking.

I can work around this problem by using fisher install jorgebucaran/nvm.fish </dev/null in a GitHub Codespaces personalized dotfile setup, and already have. Just filed this issue as a suggestion, to help others avoid running into this, because it seems weird to have to do this. (And took me some time to figure out.)

Otherwise,fisher -- could do it too. grin

I asked a friend of mine about this and he suggested if you don't like --STDIN as the name of an explicit flag to "read commands from STDIN" it would typically be named - (apparently this is a "common convention" for "read from STDIN instead of from a file name) but not -- (which typically means "stop processing options and take what follows as literal arguments").

[jorgebucaran]

t would typically be named - (apparently this is a "common convention" for "read from STDIN instead of from a file name) but not -- (which typically means "stop processing options and take what follows as literal arguments").

Yes, indeed. Your friend is absolutely correct. 👌

[jorgebucaran]

We might need a breaking change to fix this. I like using Fisher's feature for testing and debugging, like running fisher ls | fisher remove. It's great for creating pipelines, but I'm not sure how popular it is. Not keen on breaking changes now, but maybe we can search Fish dotfiles using this Fisher feature and start sending out PRs. No matter what, we can't change this until Fisher 5.

Oh, and just a heads up: this feature is mentioned in https://github.com/jorgebucaran/fisher#removing-plugins, so feel free to check it out if you're interested!

[keslerm]

Hit this myself while trying to install/setup fisher via ansible.

[jorgebucaran]

Thanks, @keslerm. I've got this squarely on my radar. 👍

[jorgebucaran]

Just wanted to drop a note for anyone following this. The main issue here is that it's a major breaking change. I find the ability to pipe things into Fisher useful as well. It's well-documented, used across tests, and has been around for a while.

That said, maybe there's a way to allow using Fisher as you intended without breaking it. I'd love to dig into this, but realistically, it's not going to happen right now unless I get a minimal reproducible example that I can easily clone and run to see the issue. If anyone's keen to move this forward faster, feel free to throw together a demo, and I'll tinker with Fisher to see if we can make it work both ways.

[JonathonRP]

fish -c "fisher update </dev/null", thank you for this was running into with my .dotfiles github codespaces and saved me, though it took me two days to find this thread 😅

[JonathonRP]

https://github.com/vorburger/dotfiles-reproduce-problem illustrates this.
https://github.com/JonathonRP/.dotfiles - without fisher installed also illustrates this.
@jorgebucaran - basically create a dotfiles repo with same files with your account set the dotfiles for dev container to your dotfiles that has copied files and watch it freeze/ not respond...

[jorgebucaran]

Thanks! This is a starting point. I think I'll dig into it more next week.