You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In asdf, a "plugin" was synonymous with a "tool". In other words, you would have a nodejs plugin which would provide the nodejs tool. As of this writing, this is the case in mise, however some work has been done to pave the way for a 1-N relationship between plugins and tools. In other words, a plugin should be able to provide multiple tools—or perhaps no tools at all for future plugins that may extend something like env or task functionality.
In essence, this is the sort of functionality I want to see assuming we had a plugin for aqua:
$ mise plugin install aqua
$ mise use -g aqua:nodejs@20
At a high-level this is the direction I like to see mise headed as more of a front-end to other tools like aqua or maybe vfox. The idea is that users would be able to use a consistent interface across multiple other tools that integrates with their env vars and tasks but leverage the great work done in other projects for things like installing tools. Projects like aqua and vfox in particular could provide alternative plugin interfaces with things like better security and non-wsl windows support.
While these could certainly be core plugins, I like the idea of making plugins capable of providing their own backends so not all that code needs to go into the core CLI.
This likely will require some decent refactoring in order to accomplish as plugins and tools have a lot of coupling that will need to be removed—though that has been a process I've slowly been chipping away at for months now to prepare for such a change.
The text was updated successfully, but these errors were encountered:
In asdf, a "plugin" was synonymous with a "tool". In other words, you would have a nodejs plugin which would provide the nodejs tool. As of this writing, this is the case in mise, however some work has been done to pave the way for a 1-N relationship between plugins and tools. In other words, a plugin should be able to provide multiple tools—or perhaps no tools at all for future plugins that may extend something like env or task functionality.
In essence, this is the sort of functionality I want to see assuming we had a plugin for aqua:
At a high-level this is the direction I like to see mise headed as more of a front-end to other tools like aqua or maybe vfox. The idea is that users would be able to use a consistent interface across multiple other tools that integrates with their env vars and tasks but leverage the great work done in other projects for things like installing tools. Projects like aqua and vfox in particular could provide alternative plugin interfaces with things like better security and non-wsl windows support.
While these could certainly be core plugins, I like the idea of making plugins capable of providing their own backends so not all that code needs to go into the core CLI.
This likely will require some decent refactoring in order to accomplish as plugins and tools have a lot of coupling that will need to be removed—though that has been a process I've slowly been chipping away at for months now to prepare for such a change.
The text was updated successfully, but these errors were encountered: