Global current working directory dynamic var

[borkdude]

Discussion for issue #1277

We could have a separate library and namespace for this:

babashka.cwd/*cwd*`

or we could just stick in into babashka.fs/*cwd*.

The idea would be that you could change the current working directory and functions in fs and process would take that into account.

We could also patch clojure core functions, but that would maybe lead to unexpected results later on if we patch things gradually.

Alternatively, we could investigate if JNI / Graal C lets us change the current working dir.

[phmeier-nubank]

Alternatively, we could investigate if JNI / Graal C lets us change the current working dir.

While looking tempting I wonder if other java tooling / library could be confused.

[borkdude]

Valid concern. Here is some info from the GraalVM slack: https://graalvm.slack.com/archives/CN9KSFB40/p1653659136057609
The tl;dr: JNI or Panama should work.

[borkdude]

With panama around the corner, we could wait for that maybe

[IGJoshua]

What in particular would you be waiting for with panama? It's already in incubator, are you waiting for a full release? Most likely that won't be happening till the next LTS release of JDK 21 in September of next year, at least based on my current expectations.

[IGJoshua]

If you need a consistent API to it across JVM versions you could pull in https://github.com/IGJoshua/coffi which won't have its external api changed much between versions and which will have a published release version for each jdk from 17 up.

[frenchy64]

Might work well for fs/process, but not a fan of patching Clojure functions.

Also, dynamic vars are somewhat brittle in Clojure when combined with laziness and parallelism.

[borkdude]

I think he already tried that, but was too much used to being able to chdir in Python :)

[frenchy64]

Hmm. Well I think binding would be the best way to implement this feature request if it's important. But someone from bash/python might be the most likely to shoot themselves in the foot with the subtle implications.

[borkdude]

Agreed. I might close this issue.

[IGJoshua]

bound-fn solves all the problems with dynamic vars and laziness, as long as people know to use them. Perhaps the problem is more with education than with dynamic variables?

[frenchy64]

Good point. I agree it's certainly possible to use correctly. Though, I think there's a cognitive overhead that should be justified by a good problem statement.

In my experience, once thread-local bindings are involved (beyond using bound-fn):

1. you have to know the implementation of every macro you use, or only use macros that explicitly promise binding conveyance.
2. as a library provider, you have to worry about your users pulling the rug out from underneath you. eg., what if you have your own cwd but someone rebinds it? or your fn cannot have its cwd changed, but the user expects it? (and every other corner case)