Committing plugin source files (completions, conf.d, functions, themes) is not supported #741
Labels
enhancement
New feature or bug fix
Comments
Maybe, why not. Would you like to send me PR with a fix that works for you? |
charego
added a commit
to charego/fisher
that referenced
this issue
Oct 29, 2022
This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list` [<regex>] - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
charego
added a commit
to charego/fisher
that referenced
this issue
Oct 29, 2022
This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list [<regex>]` - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
charego
added a commit
to charego/fisher
that referenced
this issue
Jul 3, 2023
This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list [<regex>]` - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
charego
added a commit
to charego/fisher
that referenced
this issue
Aug 21, 2023
This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list [<regex>]` - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
lediur
pushed a commit
to lediur/fisher
that referenced
this issue
Dec 5, 2023
This change is for users who commit fish_plugins and plugin sources but
omit fish_variables. On a system where Fisher's universal variables are
unset, most Fisher commands were not working out-of-the-box:
* `fisher install <plugin>` - installs <plugin>, rewrites fish_plugins file with only <plugin>
- if <plugin> is in fish_plugins, same behavior as `fisher update`
* `fisher remove <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update <plugin>` - fails with error: Plugin not installed "<plugin>"
* `fisher update` - fails with error about conflicting files, deletes fish_plugins file
* `fisher list [<regex>]` - returns nothing
As of this commit all Fisher commands work except for `fisher remove`;
Fisher still has no way of knowing which files to remove absent the
universal variable that tracks the files associated to a plugin.
It may make sense to reject calls like `fisher remove <plugin>` if the
`_fisher_<plugin>_files` universal variable is missing. Fisher could
suggest the user run `fisher update` and try again.
|
I'm not exactly sure if this is the same issue I'm dealing with, but I would like the ability to ensure that when I switch to a new computer, I can run An alternative idea would be to enable specifying locations to put plugin files so that I can deliberately avoid sourcing |
|
How did files from your plugins end up on the new machine? |
|
I've had them committed to my dotfiles repo for a while now. I can definitely remove them manually and ignore them, but I do use the functions directory for my own functions and I'd prefer to not gitignore all of the plugin files individually.
|
|
suffering same issue. When I want to recover plugins on new machine. |
|
@lianghx-319 Describe the issue, please. |
@jorgebucaran I just found that the latest version of fisher will create a fish_plugins file to store the plugin list. It's seem works when |
|
I think this issue can be closed, after update the document about the file |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would like to track not only the list of plugins (
fish_pluginsfile) but also the source code of those plugins, for a few reasons. Typically when you run "fisher update" you don't know if anything changed in your plugins. Tracking the files in git makes it easier to review changes after you pull them in, and commit them to your dotfiles once you "approve" them. Secondly, it makes provisioning a new machine easier because you don't need to install Fisher manually, the code is already in your dotfiles.The problem emerges when you want to run "fisher update" because the universal variables expected by Fisher are missing (I would prefer not to track the
fish_variablesfile). Rather than suggest a duplicate of #611 ("Fisher should stop using universal variables for plugin state"), I wonder if it would be possible for Fisher to create the universal variables on startup if they don't exist?Here is a minimal example: https://git.sr.ht/~crg/fishy
The text was updated successfully, but these errors were encountered: