Fork me on GitHub
#tools-deps
<
2018-11-07
>
seancorfield03:11:51

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 😉

❤️ 4
👍 4
jwhitlark04:11:18

Those blog posts are eagerly awaited. Do you think tools.deps has removed the need for boot, in general?

seancorfield05:11:09

I think it depends what you want from a build tool.

cfleming07:11:06

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.

👍 16
cfleming07:11:54

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.

👍 16
cfleming08:11:14

Here, root is the local :deps/root, which is generally relative.

cfleming08:11:31

Is this intentional? If not, I’ll file a bug.

cfleming08:11:34

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.

dominicm08:11:20

Always been this way, yeah

cfleming08:11:52

@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.

mpenet08:11:34

I think that also might be one of the reason katamari has vendored/forked deps for its use

cfleming08:11:11

Interesting, I’ll have to check that out.

cfleming08:11:52

Right, looks like it uses raynes/fs

cfleming08:11:52

This is kind of a show-stopper for Cursive, unfortunately.

dominicm08:11:16

Uncertain. I think there should be.

orestis17:11:42

What about CLJ_CONFIG? I remember @seancorfield uses it for something similar?

dominicm17:11:15

@orestis that's for having multiple deps.edn files. It's bad for tooling as it stops users from adding personal aliases to use.

seancorfield17:11:22

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.

seancorfield17:11:37

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' deps.edn files.

seancorfield17:11:17

That doesn't help Cursive tho', since it affects the "wrong" deps.edn file -- the "user" one, not the "project" one.

seancorfield17:11:50

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...?

dominicm17:11:23

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.

seancorfield17:11:32

In our Clojure code, we still shell out to run clojure 🙂

cfleming18:11:36

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.

cfleming18:11:44

@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 $PATH thing.

mpenet19:11:45

I guess it's jni under the hood

cfleming20:11:31

Yeah, but that would probably break all sorts of things with IntelliJ (where the logs go, etc).

dominicm19:11:42

Duh, of course

rickmoynihan19:11:50

@cfleming: is an entirely insufficient workaround to launch idea from the command line in your projects working directory?

rickmoynihan19:11:33

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

rickmoynihan19:11:22

though I don’t normally use intellij

arrdem20:11:46

@rickmoynihan yeah - most IDEA launches are through a GUI, and that defeats IDEA’s multi-project/workspace capabilities.

rickmoynihan20:11:30

… but it does work around the issue?

cfleming20:11:54

@rickmoynihan Only if you ever use one project - I usually have 3 open.

rickmoynihan20:11:41

as I said an entirely insufficient workaround

cfleming20:11:43

I actually don’t even know how to run a Mac app from a specified directory, or if it’s even possible.

rickmoynihan20:11:06

/Applications/IntelliJ\ does it for me

cfleming20:11:40

For now, I’ll probably just have to do the same horrible hacks I do for leiningen using hooke or the moral equivalent.

cfleming20:11:29

@arrdem Has raynes/fs worked well for your vendored fork?

cfleming20:11:49

Looking at the code, I assume this sort of problem is what you’re trying to deal with?

arrdem20:11:51

@cfleming Yeah. It was a bit fiddly to figure out where I needed it, but I haven’t had problems with it since.

arrdem20:11:06

You’re right, that is why I patched it in.

cfleming20:11:28

Are there places where you don’t want it? If I use hooke, then that’s pretty global.

arrdem20:11:05

Can you hooke or alter-var-root on io/file? That seems like a really big hammer and may play badly with static linking.

arrdem20:11:14

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.

cfleming21:11:31

(sorry, got called away there)

cfleming21:11:56

Yeah, that’s what I do. It’s scoped to a particular sequence of calls, but during that sequence it’s globally modified, yes.

cfleming21:11:25

It seems to work, and I think it works because the code calling io/file is not statically linked, so it uses the var.

cfleming21:11:36

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.

arrdem21:11:01

For katamari it’s as much a proof that katamari’s heavily vendored monorepo workflow actually does work.

cfleming21:11:03

All options suck, basically.

arrdem21:11:11

fork && vendor && move on

cfleming21:11:33

I can’t wait for the bug reports saying that Cursive xxx doesn’t support the functionality that was introduced in deps yyy

arrdem21:11:14

yeah I need to write some bash + sed automation to let me packport merged diffs ~automatically.

cfleming22:11:54

The problem I have with that is that I can’t rely on everyone upgrading Cursive, so older versions will still be out there with older versions of tools.deps baked in.