tools-deps

Discuss tools.deps.alpha, tools.build, and the clj/clojure command-line scripts! See also #depstar #clj-new
kirill.salykin 2021-04-01T09:57:05.316300Z

is it possible to include some java.class with deps.edn? I found example with .jar , but is it possible to include just one .class file?

thheller 2021-04-01T09:58:38.316800Z

you can take it out of the .jar and just put in some path you add via :paths

kirill.salykin 2021-04-01T10:00:36.317Z

nice, thanks!

kirill.salykin 2021-04-01T10:05:56.317100Z

should I specify the full path to a class file? eg

:paths ["lib/some.class"]
or to root?
:patsh ["lib"]

kirill.salykin 2021-04-01T10:05:59.317300Z

thanks

thheller 2021-04-01T10:14:20.317500Z

the class needs to have the same path that is has in the jar

thheller 2021-04-01T10:14:38.317700Z

so foo/bar/thing.class you put into lib/foo/bar/thing.class with :paths ["lib"]

kirill.salykin 2021-04-01T10:15:35.317900Z

thanks giving it a try

kirill.salykin 2021-04-01T10:22:06.318100Z

thanks a lot, works

seancorfield 2021-04-01T17:13:51.321300Z

@alexmiller I’m running into that hard-to-repro failure with git deps and I’m beginning to think it has to do with :deps/root. I had the following in my deps.edn aliases:

:poly {:main-opts ["-m" "polylith.clj.core.poly-cli.core"]
                   :extra-deps {polyfy/polylith
                                {:git/url   "<https://github.com/polyfy/polylith>"
                                 :sha       "2d89676724e98d4c1b858c28c452cf2a64fc1b1c"
                                 :deps/root "projects/poly"}}}
I updated the SHA to 499401d4d2c5ac206f00a35c2cd8e569e4e6c3a8 and when I re-ran that alias I got
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate polylith/clj/core/poly_cli/core__init.class, polylith/clj/core/poly_cli/core.clj or polylith/clj/core/poly_cli/core.cljc on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
It isn’t happening every time, but after nuking ~/.gitlibs it re-cloned and things worked. Then I updated the SHA to 1ae83891e5910fd1c2e130527a0571419ff3d257 and it failed again. Nuking ~/.gitlibs solved it again.

seancorfield 2021-04-01T17:14:16.321600Z

And this is purely on

Clojure CLI version 1.10.3.814

seancorfield 2021-04-01T17:18:19.324900Z

Also, something that seemed very strange to me: I checked out that repo locally and switched the (working) :git/url to a :local/root pointing to the folder where I checked it out. I verified the HEAD SHA in the local checkout matched the :sha I had been using, and commented out the :git/url and :sha keys — leaving just :local/root and :deps/root — and that fails with

Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate polylith/clj/core/poly_cli/core__init.class, polylith/clj/core/poly_cli/core.clj or polylith/clj/core/poly_cli/core.cljc on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
I would have expected :local/root / :deps/root and :git/url / :sha / :deps/root to behave identically if the local checkout is at the same SHA. Am I misunderstanding something about local root deps?

seancorfield 2021-04-01T17:20:24.325800Z

(switching the :local/root to point to &lt;repo&gt;/projects/poly directly works — I thought :deps/root worked with :local/root but I guess it doesn’t?)

alexmiller 2021-04-01T17:23:02.326200Z

when this happens, can you check the sha dir? I assume it's empty

alexmiller 2021-04-01T17:24:54.327300Z

local/root to the sha dir in gitlibs should be comparable (both from that point use the identical code to read the manifest, deps, paths etc), although there could be differences in dir resolution related to absolute/relative

alexmiller 2021-04-01T17:26:31.328400Z

if you get into the first scenario, and can save off your gitlibs dir, would be interested in looking at it more

alexmiller 2021-04-01T17:27:58.329900Z

in particular, I'm curious about the timeline of the sha update, whether it's a case like: • use git dep at sha X • project pushes new sha • you switch git dep to new sha Y (not included in the original clone when getting X)

alexmiller 2021-04-01T17:28:35.330600Z

in that case, it should try to resolve Y, fail, fetch to update the git dir, then re-resolve (successfully)

alexmiller 2021-04-01T17:29:36.331200Z

also, there are known issues with gitlibs and git submodules and that doesn't work right now (I doubt you're doing that but just in case)

seancorfield 2021-04-01T17:57:34.331600Z

Ah, maybe because these SHAs are on a branch, not on the default?

seancorfield 2021-04-01T18:03:15.331900Z

(and, yes, the sha dir was empty)

seancorfield 2021-04-01T18:04:52.332900Z

And also, yes, this is when I’ve been working against a SHA (on a non-default branch) and the maintainer pushes an update on that branch and I switch to the newer SHA on that branch.

alexmiller 2021-04-01T18:24:55.333500Z

branch should be unimportant

alexmiller 2021-04-01T18:25:43.334500Z

next time you do it, you can also set GITLIBS_DEBUG=true and it will print all the git commands it's running - you should see the fetch happen

seancorfield 2021-04-02T23:17:00.339800Z

Darn! I forgot to add that var when I updated again. It broke again:

Error building classpath. Manifest type not detected when finding deps for polyfy/polylith in coordinate {:git/url "<https://github.com/polyfy/polylith>", :sha "783916018b20a76f9054af8086e09e8f3335a3ae", :deps/root "projects/poly"}

seancorfield 2021-04-02T23:17:30.340Z

I saved the poly-related ~/.gitlibs pieces for you in a tar file after it broke.

seancorfield 2021-04-02T23:20:47.340200Z

(! 1176)-&gt; ls libs/polyfy/polylith/
1ae83891e5910fd1c2e130527a0571419ff3d257/
2d89676724e98d4c1b858c28c452cf2a64fc1b1c/
Those are the two earlier SHAs. There’s no corresponding folder for the new SHA (above).

seancorfield 2021-04-02T23:37:14.340400Z

Pretty sure I’ll get another chance at this, maybe tomorrow.

seancorfield 2021-04-03T04:02:38.341Z

seanc@DESKTOP-30ICA76:~/oss/usermanager-example$ GITLIBS_DEBUG=true clojure -Sforce -M:poly test :all :dev
git --git-dir /home/seanc/.gitlibs/_repos/github.com/polyfy/polylith rev-parse 500c31e95f88a80036b74c9b20712122bbf25a34^{commit}
fatal: ambiguous argument '500c31e95f88a80036b74c9b20712122bbf25a34^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git &lt;command&gt; [&lt;revision&gt;...] -- [&lt;file&gt;...]'
git --git-dir /home/seanc/.gitlibs/_repos/github.com/polyfy/polylith fetch --quiet --tags
git --git-dir /home/seanc/.gitlibs/_repos/github.com/polyfy/polylith rev-parse 500c31e95f88a80036b74c9b20712122bbf25a34^{commit}
fatal: ambiguous argument '500c31e95f88a80036b74c9b20712122bbf25a34^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git &lt;command&gt; [&lt;revision&gt;...] -- [&lt;file&gt;...]'
Error building classpath. Manifest type not detected when finding deps for polyfy/polylith in coordinate {:git/url "<https://github.com/polyfy/polylith>", :sha "500c31e95f88a80036b74c9b20712122bbf25a34", :deps/root "projects/poly"}

alexmiller 2021-04-03T12:04:08.342200Z

thx, that's exactly what I needed and the fact that it was on a branch was important!

alexmiller 2021-04-03T12:05:18.342400Z

new prerelease of clj 1.10.3.822 available for you to test - you will need to rm your ~/.gitlibs (or at least the _repos) to have the fix take affect as it is both a change in the initial clone and a change in the working tree checkout

seancorfield 2021-04-03T19:52:36.360900Z

Thanks. I'll update both systems now and blow away ~/.gitlibs. I'll let you know if I run into any more issues.

seancorfield 2021-04-05T18:16:35.381900Z

Here’s the debug output when I updated my SHA this morning (and it worked — thank you!):

(! 997)-&gt; GITLIBS_DEBUG=true clojure -M:poly libs
git --git-dir /Users/sean/.gitlibs/_repos/github.com/polyfy/polylith rev-parse 65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8^{commit}
fatal: ambiguous argument '65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git &lt;command&gt; [&lt;revision&gt;...] -- [&lt;file&gt;...]'
git --git-dir /Users/sean/.gitlibs/_repos/github.com/polyfy/polylith fetch --quiet --all --tags --prune --prune-tags
git --git-dir /Users/sean/.gitlibs/_repos/github.com/polyfy/polylith rev-parse 65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8^{commit}
Checking out: <https://github.com/polyfy/polylith> at 65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8
git --git-dir /Users/sean/.gitlibs/_repos/github.com/polyfy/polylith worktree add --force --detach /Users/sean/.gitlibs/libs/polyfy/polylith/65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8 65a7918bb6de886cda7a9b8a5fe7dbdf10996bf8

seancorfield 2021-04-05T18:17:13.382100Z

Although that fatal error sounds like a bug?

alexmiller 2021-04-05T18:43:24.382500Z

No, that’s expected

alexmiller 2021-04-05T18:43:46.383200Z

It’s trying to resolve the commit and when it fails, that’s what triggers the fetch

alexmiller 2021-04-05T18:45:15.384200Z

Avoiding the unnecessary fetch when it can be resolved is a big help perf wise

seancorfield 2021-04-05T19:10:30.384500Z

Gotcha. Better to try and fail to make the happy path faster.

seancorfield 2021-04-01T18:28:21.334800Z

OK, will try that. Thanks.

alexmiller 2021-04-01T18:34:12.336Z

I did run tests around scenarios like this, and I believe it should be working, but it seems like the problem area

seancorfield 2021-04-01T18:34:41.336400Z

I should get a chance to test it later today I expect 🙂

alexmiller 2021-04-01T19:27:30.337100Z

this was broken prior to 814, and old prerelease stuff in your gitlibs dir would maybe fail if you had that

seancorfield 2021-04-01T19:30:11.337700Z

I completely blew away ~/.gitlibs when I updated to 814 (and I’ve actually blown it away a couple of times since).