Fork me on GitHub
#tools-deps
<
2019-11-14
>
plexus09:11:23

I quite like having wrapper scripts for this, this is also why I promote adding a bin/kaocha to projects. That also gives you an opportunity to further reduce friction by doing extra setup steps, doing precondition checks (e.g. minimum java version), setting environment variables, passing along JVM options, ...

rickmoynihan10:11:03

@plexus: Yeah we use kaocha; it’s great, thanks for that btw 🙂 Though I think adding bin scripts is a bit of a hack/workaround, as it’s opaque to introspection and tool support. Which is another thing projects (particularly internal ones) then need to document; often for each editor/environment in use on the team.

plexus10:11:53

I agree, but I think that's exactly why they are great, they are executable documentation. I'd rather see bin/cider_repl / bin/proto_repl / ... then having one liners in the README (not too bad) or having them shared ad-hoc through back channels (more common). It removes friction and cognitive overhead for the most common cases. You can still pass on extra args to clojure, and if that doesn't cut it then run it with bash -x, copy the final command into your shell and take it from there.

plexus10:11:14

it also means most developers are doing the same thing. I've been on too many projects where it turns out every single person runs their dev process slightly different from everyone else, causing all kinds of reproducibility issues.

rickmoynihan11:11:24

TIL. nice tip: > run it with bash -x, copy the final command into your shell and take it from there.

rickmoynihan11:11:04

> I’ve been on too many projects where it turns out every single person runs their dev process slightly different from everyone else, causing all kinds of reproducibility issues. I think this is a side effect tools.deps has encouraged, by doing less. Expectations and workflows on lein projects were typically more uniform.

seancorfield17:11:32

It's why we have a standardized build script that runs clojure, and also why we have a standardized "baseline" deps.edn which we control via CLJ_CONFIG in the build script.

seancorfield17:11:18

No user-level aliases interfering. No possibility of different versions across the team.

seancorfield17:11:41

The baseline deps.edn contains all the aliases that anyone needs.