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
From #2555. The context is bundling as part of a third party installer and still making sure that everything is set up nicely (and in isolation!).
Where does spin store the plugins and templates
Ideally I wouldn't need to know, but since I can't use the cli to query if templates and plugins have been installed or not, I needed to check the filesystem.
I could not find a way to find the directory from the command itself, like I can do with e.g. docker:
$ docker info -f json | jq -r .DockerRootDir
/var/lib/docker
It would be nice to have a similar spin info subcommand that provides the data directory location, e.g.
$ spin info --json | jq -r .SpinAppData
/Users/jan/Library/Application Support/spin
The rules for locating the data directory are complex
Since I can't query the spin app data location, I have to hard-code the rules from the spin app into the installer:
Unfortunately it gets more complicated: On Linux it will be $XDG_DATA_HOME/spin if XDG_DATA_HOME is defined. #1494 makes the location dependent on installation by Homebrew, and #641 promises to make things even more complex.
I think replicating all these rules in a 3rd-party installer is bad, but it gets even worse when you consider GUI applications. They are not started from the user's shell, but e.g. on macOS from launchd on behalf of Finder.app. Those apps don't inherit the user's shell environment variables. You could try to look up the default shell for the user from /etc/passwd and then run a login shell as a subprocess to query the environment variables, but this is getting just too convoluted, and is still not guaranteed to be correct 100% of the time either.
The text was updated successfully, but these errors were encountered:
@jandubois The request here seems to be the result of a chain of challenges unfolding from "since I can't use the cli to query if templates and plugins have been installed." With the suggested solution for finding out if templates are installed (redirecting stderr), and the PR for listing plugins in JSON, is this still a blocker / priority for you?
Starting with the upcoming Rancher Desktop 1.17.0 release we will make use of the SPIN_DATA_DIR functionality (thanks for implementing this), will create wrappers to spin to set this up. Conceptually:
In addition we will make sure on each start of Rancher Desktop that the templates and plugins installed in that directory match the versions we have pinned, to make sure they are compatible with the spinkube operator that is also bundled.
Users are always free to put the upstream binary of spin into a directory earlier on the PATH and are then responsible themselves to make sure everything is compatible.
So Rancher Desktop no longer has a need to determine the location of the spin data directory; it prescribes it for the bundled utilities.
From #2555. The context is bundling as part of a third party installer and still making sure that everything is set up nicely (and in isolation!).
Where does spin store the plugins and templates
Ideally I wouldn't need to know, but since I can't use the cli to query if templates and plugins have been installed or not, I needed to check the filesystem.
I could not find a way to find the directory from the command itself, like I can do with e.g. docker:
It would be nice to have a similar spin info subcommand that provides the data directory location, e.g.
The rules for locating the data directory are complex
Since I can't query the spin app data location, I have to hard-code the rules from the spin app into the installer:
Unfortunately it gets more complicated: On Linux it will be $XDG_DATA_HOME/spin if XDG_DATA_HOME is defined. #1494 makes the location dependent on installation by Homebrew, and #641 promises to make things even more complex.
I think replicating all these rules in a 3rd-party installer is bad, but it gets even worse when you consider GUI applications. They are not started from the user's shell, but e.g. on macOS from launchd on behalf of Finder.app. Those apps don't inherit the user's shell environment variables. You could try to look up the default shell for the user from /etc/passwd and then run a login shell as a subprocess to query the environment variables, but this is getting just too convoluted, and is still not guaranteed to be correct 100% of the time either.
The text was updated successfully, but these errors were encountered: