cli
cli copied to clipboard
snowjs
snow install fails on linux
The install command is currently only supporting mac. Would be nice to check the OS and use different dependencies arrays for each OS. Might be a good idea to extract the dependencies arrays into own files. Maybe create a folder for the install command?
Supporting linux is going to be important for users wishing to use snow in ci-type environments, and all snow commands should work on Mac OS and Linux.
50,000 foot view: I'm not 100% sure how I feel about the snow install command, because solving the problem of installing dependencies in a cross-platform manner isn't core to this project, but it's existence would ease adoption of the CLI tool. With respect to Linux, there's the Linuxbrew project, but I'm unsure of how viable of an option that is.
Another option would be to add a table to the README with install commands, similar to how node-canvas has done:
| OS | Command |
|---|---|
| OS X | brew install pkg-config cairo libpng jpeg giflib |
| Ubuntu | sudo apt-get install libcairo2-dev libjpeg-dev libpango1.0-dev libgif-dev build-essential g++ |
| Fedora | sudo yum install cairo cairo-devel cairomm-devel libjpeg-turbo-devel pango pango-devel pangomm pangomm-devel giflib-devel |
| Solaris | pkgin install cairo pkg-config xproto renderproto kbproto xextproto |
| Windows | Instructions on our wiki |
(Note: these commands are for canvas, and not snow). Personally, I feel this simpler approach isn't any more burdensome-- running one of the above commands would be nearly analogous to snow install.
I'd also like to point out that the snow create command relies on openssl being in the user's path, but we don't check for it in snow install -- but while we're on the topic of discussing binaries snow depends on, we should address that as well.
Tough decision. I think the install command could help in spreading snow because getting started is so easy. But this only works if the install is robust and does not throw (sometimes) errors. Otherwise the UX is destroyed.
Another approach to this problem is to reduce the number of needed CLI dependencies. It's probably not feasible to remove all of Snow's CLI dependencies. However, substituting in some JS clients could make a sizable dent, and JS clients might behave a bit more predictably (e.g., when errors are thrown, we're simply monitoring process exit codes).
- The official k8s client could replace usage of
kubectl-- which is used in every command, exceptinstall. - The official GKE client could replace some usage of
gcloudin theinstallcommand. - forge might cover our needs for certificate creation, allowing us to remove our dependency on
openssl, which we use for helm. - The unofficial Digital Ocean client could replace the entirety of
doctlusage in thecreatecommand.
It would be difficult to remove helm. Helm has no language-specific client libraries, and we use it to easily install nginx-ingress, cert-manager, and docker-registry. Since all helm is automating is the creation of a bunch of resources... we could manually create those ourself. Helm v3 is completely removing tiller and its server/client model, so openssl should go away regardless.
Glad I did this research, but given all of these complexities involved in moving towards a fully JS-based solution, the best and most straightforward option maybe implementing cross-OS support for install.
Per the good folks on the Kubernetes #helm-dev slack channel, the v3 pre-release is landing in a couple weeks too. Could be worthwhile to wait for that.