search

snowjs / cli

CLI tool for dead-simple serverless Docker deployments on managed Kubernetes services. A self-hosted PaaS. ⚡️
https://github.com/snowjs/cli/tree/secrets
MIT License
409 stars 10 forks source link

snow install fails on linux #9

Open sean-nicholas opened 5 years ago

sean-nicholas commented 5 years ago

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?

petermikitsh commented 5 years ago

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.

petermikitsh commented 5 years ago

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.

sean-nicholas commented 5 years ago

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.

petermikitsh commented 5 years ago

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).

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.

petermikitsh commented 5 years ago

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.