Fork me on GitHub
#tools-deps
<
2021-04-01
>
kirill.salykin09:04:05

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?

thheller09:04:38

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

kirill.salykin10:04:56

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

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

thheller10:04:20

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

thheller10:04:38

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

kirill.salykin10:04:35

thanks giving it a try

kirill.salykin10:04:06

thanks a lot, works

seancorfield17:04:51

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

seancorfield17:04:16

And this is purely on

Clojure CLI version 1.10.3.814

seancorfield17:04:19

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?

seancorfield17:04:24

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

Alex Miller (Clojure team)17:04:02

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

Alex Miller (Clojure team)17:04:54

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

Alex Miller (Clojure team)17:04:31

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

Alex Miller (Clojure team)17:04:58

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)

Alex Miller (Clojure team)17:04:35

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

Alex Miller (Clojure team)17:04:36

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)

seancorfield17:04:34

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

seancorfield18:04:15

(and, yes, the sha dir was empty)

seancorfield18:04:52

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.

Alex Miller (Clojure team)18:04:55

branch should be unimportant

Alex Miller (Clojure team)18:04:43

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

seancorfield23:04:00

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 "", :sha "783916018b20a76f9054af8086e09e8f3335a3ae", :deps/root "projects/poly"}

seancorfield23:04:30

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

seancorfield23:04:47

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

seancorfield23:04:14

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

seancorfield04:04:38

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 <command> [<revision>...] -- [<file>...]'
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 <command> [<revision>...] -- [<file>...]'
Error building classpath. Manifest type not detected when finding deps for polyfy/polylith in coordinate {:git/url "", :sha "500c31e95f88a80036b74c9b20712122bbf25a34", :deps/root "projects/poly"}

Alex Miller (Clojure team)12:04:08

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

Alex Miller (Clojure team)12:04:18

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

seancorfield19:04:36

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

seancorfield18:04:35

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

(! 997)-> 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 <command> [<revision>...] -- [<file>...]'
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:  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

seancorfield18:04:13

Although that fatal error sounds like a bug?

Alex Miller (Clojure team)18:04:46

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

Alex Miller (Clojure team)18:04:15

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

seancorfield19:04:30

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

seancorfield18:04:21

OK, will try that. Thanks.

Alex Miller (Clojure team)18:04:12

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

seancorfield18:04:41

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

Alex Miller (Clojure team)19:04:30

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

seancorfield19:04:11

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