reading https://boats.gitlab.io/blog/post/2018-01-18-configure/ … and thinking what would the "rails of cli apps" look like?
-
Show this thread
-
by rails i mean, 1. decent defaults 2. scaffolding generated for you 3. convention over configuration
3 replies 0 retweets 12 likesShow this thread -
Replying to @steveklabnik
I started to work on this with Thor back in the day, but 1. I was a young and naive programmer 2. I didn't have enough time to really sink into it 3. As a rails dep it's hard to move But I still think I got a lot right
3 replies 0 retweets 5 likes -
Replying to @wycats @steveklabnik
Seems like a hard problem to generalize since most configuration you’re solving on behalf of the user is usually really domain driven. I did try to start a basic one a while back as well.
1 reply 0 retweets 1 like -
I say this hoping you correct me, because I’m interested how this could be solved in a general way. Pluggable configuration standards?
1 reply 0 retweets 1 like -
Replying to @richardiii @steveklabnik
Both bundler and cargo standardized around a few basic ways to get config in (local/global files, env vars) where every config has an equivalent (easy to drerive) env var, even for arrays and such. That story is easy to make conventional and valuable.
1 reply 0 retweets 2 likes
In a lot of ways the problem is similar to rails: there's a lot of pointless scaffolding leading into an endpoint with params, some common kinds of (unimportant) persistence, and then the app takes it from there.
-
-
Replying to @wycats @steveklabnik
Speaking of being a naive programmer, I was thinking at a much higher level. Appreciate the reply as always
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.