This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (15)
- # beginners (186)
- # boot (11)
- # bristol-clojurians (1)
- # clara (1)
- # cljdoc (2)
- # cljs-dev (5)
- # clojure (57)
- # clojure-austin (1)
- # clojure-dev (87)
- # clojure-italy (7)
- # clojure-spec (5)
- # clojure-uk (56)
- # clojurescript (18)
- # cursive (29)
- # data-science (10)
- # datomic (84)
- # duct (83)
- # figwheel-main (4)
- # fulcro (42)
- # jobs (3)
- # lambdaisland (2)
- # off-topic (28)
- # parinfer (3)
- # portkey (3)
- # re-frame (28)
- # reitit (7)
- # remote-jobs (8)
- # shadow-cljs (29)
- # spacemacs (30)
- # specter (6)
- # sql (8)
- # tools-deps (60)
Deleted the last vestiges of Boot from our system today (on dev). I decided to even convert two legacy system pieces since they are going to be around for a few months and it seemed silly to keep Boot around just for those. Very pleased with nice, simple, lean processes we have now. And we're on Clojure 1.10 Beta 5 in dev as well. Several blog posts to come 😉
Those blog posts are eagerly awaited. Do you think tools.deps has removed the need for boot, in general?
I think it depends what you want from a build tool.
I’ve talked about some variant of this in the past, but I can’t remember the exact details now. It seems to be impossible to use tools.deps as a library from a process which doesn’t have the CWD set to the directory containing the main deps.edn file. This seems like a significant limitation - it means you can never have a process which resolves deps from two separate deps.edn files, for example.
The problem is that if your deps.edn file references another using
:local/root, the paths are incorrect - the paths from the dependency are relative to the CWD, not to the deps.edn file location.
The problem is here: https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/extensions/deps.clj#L29
I was somewhat convinced that this wasn’t previously the case, but it seems to have been this way for some time according to git.
@dominicm Is there an issue for it? There’s TDEPS-74 but that’s the transitive one. I can’t see anything else likely-looking.
I think that also might be one of the reason katamari has vendored/forked deps for its use
What about CLJ_CONFIG? I remember @seancorfield uses it for something similar?
@orestis that's for having multiple deps.edn files. It's bad for tooling as it stops users from adding personal aliases to use.
Well, it's good for projects that want a specific
deps.edn "base" file instead of using whatever the developer happens to have in their
.clojure/deps.edn file -- so it really depends on your perspective.
For our monorepo, we specify all our defaults (some aliases, but mostly
:override-deps) in a
versions/deps.edn file and we use
CLJ_CONFIG to use that as our basis for all the subprojects'
That doesn't help Cursive tho', since it affects the "wrong"
deps.edn file -- the "user" one, not the "project" one.
In one place, we shell out to the
clojure command and when we do that (via
clojure.java.shell/sh) we specify the
:dir that it should be executed in so
CWD is controlled. I'm not sure how Cursive invokes this stuff -- I suspect it is trying to use t.d.a. directly and that's where the problem occurs...?
cursive is java, so it's using it as a library rather than shelling out. I think @cfleming mentioned that $PATH isn't set in cursive.
In our Clojure code, we still shell out to run
What I want is to get the full Java command line that I need to execute, so that I can execute it with IntelliJ’s command running infrastructure. There’s no way to get that from the command line with clj.
@dominicm The issue is that if you use t.d.a as a lib, there’s no way to set the CWD of a running Java process. It’s not a
Apparently there's a way with jruby https://github.com/arohner/lein-daemon/blob/master/daemon-runtime/src/leiningen/daemon/runtime.clj
Yeah, but that would probably break all sorts of things with IntelliJ (where the logs go, etc).
@cfleming: is an entirely insufficient workaround to launch
idea from the command line in your projects working directory?
IIRC I’ve done that in the past with intellij; when I’ve run into issues with macos/quartz-UI not being a child of a shell environment
though I don’t normally use intellij
@rickmoynihan yeah - most IDEA launches are through a GUI, and that defeats IDEA’s multi-project/workspace capabilities.
… but it does work around the issue?
@rickmoynihan Only if you ever use one project - I usually have 3 open.
as I said an entirely insufficient workaround
I actually don’t even know how to run a Mac app from a specified directory, or if it’s even possible.
/Applications/IntelliJ\ does it for me
For now, I’ll probably just have to do the same horrible hacks I do for leiningen using hooke or the moral equivalent.
Looking at the code, I assume this sort of problem is what you’re trying to deal with?
@cfleming Yeah. It was a bit fiddly to figure out where I needed it, but I haven’t had problems with it since.
Are there places where you don’t want it? If I use hooke, then that’s pretty global.
Can you hooke or alter-var-root on io/file? That seems like a really big hammer and may play badly with static linking.
In general I couldn’t prove that things wouldn’t behave precisely as expected and erred on the side of caution, so I did the refactor by hand and it took a couple passes.
Yeah, that’s what I do. It’s scoped to a particular sequence of calls, but during that sequence it’s globally modified, yes.
It seems to work, and I think it works because the code calling
io/file is not statically linked, so it uses the var.
I’m not sure whether that’s better or worse than vendoring a specific version of deps, which is then tied to that version of Cursive.
For katamari it’s as much a proof that katamari’s heavily vendored monorepo workflow actually does work.
I can’t wait for the bug reports saying that Cursive xxx doesn’t support the functionality that was introduced in deps yyy
yeah I need to write some bash + sed automation to let me packport merged diffs ~automatically.