Fork me on GitHub
#tools-deps
<
2022-05-02
>
Eugen11:05:37

Is there any way I can exclude files ?! I have an issue with what might be a broken shaded jar. The issue is because the jar manifest has signatures that are not valid ?! At least that is what I understand. deps.edn:

{:paths ["src" "test" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"}
        org.apache.directory.server/apacheds-all {:mvn/version "2.0.0.AM26"}}}
the file
(ns user
  (:import (org.apache.directory.server.core
            DefaultDirectoryService)))
the error
; Evaluating file: core.clj
; Execution error (SecurityException) at sun.security.util.SignatureFileVerifier/processImpl (SignatureFileVerifier.java:316).
; Invalid signature file digest for Manifest main attributes
; Evaluation of file core.clj failed: class clojure.lang.Compiler$CompilerException
clojure.lang.Compiler/load (Compiler.java:7665)
ieugen.ldap-auth-provider.core/eval7557 (NO_SOURCE_FILE:1)
clojure.lang.Compiler/eval (Compiler.java:7194)
clojure.core/eval (core.clj:3215)
clojure.core/eval (core.clj:3211)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.core/apply (core.clj:667)
clojure.core/with-bindings* (core.clj:1990)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:87)
clojure.main/repl (main.clj:437)
clojure.main/repl (main.clj:458)
clojure.main/repl (main.clj:368)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:84)
nrepl.middleware.interruptible-eval/evaluate (interruptible_eval.clj:56)
nrepl.middleware.interruptible-eval/interruptible-eval (interruptible_eval.clj:152)
nrepl.middleware.session/session-exec (session.clj:218)
nrepl.middleware.session/session-exec (session.clj:217)
java.lang.Thread/run (Thread.java:829)

Eugen11:05:41

I managed to get around this by including all the jars instead of the shaded -all jar .

Eugen11:05:55

but would be nice to know if there are some knobs in deps

seancorfield15:05:23

:exclusions tells it to omit a specific (transitive) dependency.

Eugen16:05:11

i think the issue is with the jar manifest and the fact that those files exist there with different checksums

Eugen16:05:20

I am not familiar with the details

Eugen16:05:36

so exclusions might not work in this case

dominicm21:05:34

Unfortunately you can't exclude individual files from jars.

👍 1
grzm14:05:06

Hello! I’ve just recently started using clojure.tools.deps as a library (as opposed to via the clj command line tool), and am seeing WARNING: Use of :paths external to the project has been deprecated, please remove: for the first time. We have a monorepo. Each module in the monorepo has its own deps.edn, expressing dependencies on other modules using :local/root. I can imagine motivations for wanting to flag external paths, and I can also imagine scenarios where this is safe. We always want to depend on HEAD: we never want to refer to a specific commit for these dependencies, so using [:git/url :git/sha] and bumping those each time is something we’d rather avoid.

grzm14:05:21

This warning has been in the clojure.tools.deps for a long time (over a year), so I imagine there’s been discussion around this in the past. If people have references at hand to point me to, that’d be appreciated: I don’t mean to rehash all of this if it’s already been addressed.

grzm14:05:40

It looks like https://clojure.atlassian.net/browse/TDEPS-132 is set up to address this.

seancorfield15:05:44

We have a large monorepo and use :local/root without that warning -- so you must have :paths that point outside the local deps.edn project scope as well? What are you using :paths for that isn't a "local" directory?

grzm17:05:34

I think I’m seeing when using the clojure.tools.deps library directly (e.g., referring to the clojure.tools.cli.api namespace for monorepo operations). We’re not seeing it when running daily clj commands that rely on the same deps.edn files.

grzm17:05:12

And it’s pointing to all of our local/roots, not some exception.

seancorfield17:05:04

That warning comes from :paths, not :local/root -- the latter can point outside a project. And if you're not seeing it from the CLI, maybe your CLI is out of date and using a much older t.d.a?

grzm17:05:54

Oh, good call. Thank you, rubber ducky 🙂 (seancorfield rubber ducky is the best rubber ducky)

duckie 1
grzm16:05:48

So, I got to the root of the issue: when supplying a deps-map to clojure.tools.deps.alpha/create-basis via :project. Supplying a path to the source deps.edn file doesn’t have this issue.

grzm17:05:58

So, what I think is happening is that the :local/root in deps is pulling in :paths from those project’s deps.edn files, and those paths are (unsurprisingly) relative to those projects, and external to wherever create-basis thinks the project root is (probably the user.dir, but maybe it knows it doesn’t have one set) clojure.tools.deps.alpha/validate-paths calls out these paths as external.

grzm17:05:59

Close, but wrong again. The deps-map I was passing as {:project deps-map} contained absolute paths to paths external to user.dir , which I think is assumed to be project root. Thank you all for your unwilling patience and witnessing me think this through in public.

1