Hello!
I’m experimenting with habitat development process and I think it will be interesting: The Habitat Development SDK!
Quick example for now, as it all in development yet:
sudo hab pkg install ya/hab-plan-make-shellcheck
sudo hab pkg binlink ya/hab-plan-make-shellcheck make-shellcheck
make-shellcheck --help
make-shellcheck core-plans/consul
Embed in the build:
...
pkg_build_deps+=(ya/hab-plan-make-shellcheck)
...
do_prepare() {
hab-plan-make-shellcheck $PLAN_CONTEXT
}
pkg_build_deps+=...
Whoa! I didn’t realize you could append variables in bash like that! I’m going to have to use that in my current application plans. 
W.R.T to what you shared, we also embed most of our CI related things inside the pkg_build_deps as well. Things like linters, style-checkers and any other static code analyzers. We try to bake in as much as possible into the plan so that all of our devs just focus on one simple build command without worry of missing any tooling.
One thing to keep in mind, within a build context, if the pkg is in your deps, then the tool will be in your path. If you want to use the tool outside of the build context then it’s necessary to do what you just did which is install the tool and binlink.
For outside of plan cases wrapper make-<thing> was added.
There is also plan.toml now: https://github.com/habitat-plans/hab-plan-sdk
We also do a lot of local dev in the Studio here at smartB (unfortunately I can’t share source code for everything we do yet, but I’m working towards that). One pain point for us is the need to drop into a debugger like pry or ipdb for a Ruby or Python service. Using the Supervisor (has svc load $pkg_ident) inside the Studio doesn’t really work for us. I’ve considered adding a variable like pkg_svc_debug_run to the Plan to enable this better (we source our plan.sh files quite heavily for use with local dev shell functions that we define in .studiorc).
Can we use Scaffolding to share around a set of common Studio dev tools and tricks?
@bixu, I understand you case and hope I can deal with it too.
For now I’m test-driving tools with as minimal as possible features. I need a proof concept that it will might work well in different setups.
I’m expecting that community will come to a common approach and hab-plan-whatever will do this trick by default. In case you need some customization - you have plan.toml. You even can have multi-component project and only root-plan.toml (cli supports --plan-toml). Many bash-tricks from .studiorc will go away.
For your particular case I have in todo the following:
hab-plan-make-service - control how to load/unload/bind your service and dependent services if any
hab-plan-make-run - control how to run your cli/service.
In conjunction with hab-plan-make-bats and hab-plan-make-inspec it looks for me like a super cool solution.
I don’t know if scaffolding is the way to do it. We’ve actually had these conversations internally quite a lot because we have teams here that are using the .studiorc quite heavily as well. In fact on the builder team we have a custom .studiorc that mutates the studio to add functions and the like so that we can pack it with tools we need to make development on the project cleaner. Point is we do know we need a first class developer experience in the studio and today it’s just not quite there. Any suggestions would be greatly appreciated especially in the form of issues!
We are also one of those teams where we stuff a bunch of functionality into our .studiorc. We have baked in developer tools that need to be installed and what not.
What seems to be a big mess is trying to play nicely with things like gdb, gdbserver, etc. A lot of the IDEs that integrate visual debuggers, like VS Code, allow you to remote into things or if the process is local allow you to bind to it and you can do debugging. However, with your process run from within the studio, it’s a bit of an entanglement. I wish there was a way to kind of “ssh” commands into the studio.