This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-08
Channels
- # announcements (43)
- # architecture (4)
- # beginners (115)
- # calva (6)
- # cider (4)
- # circleci (4)
- # clara (3)
- # clj-kondo (6)
- # cljs-dev (10)
- # cljsrn (1)
- # clojars (1)
- # clojure (108)
- # clojure-boston (1)
- # clojure-dev (4)
- # clojure-europe (5)
- # clojure-italy (6)
- # clojure-nl (13)
- # clojure-uk (17)
- # clojurescript (47)
- # core-async (2)
- # cursive (13)
- # data-science (1)
- # datavis (15)
- # datomic (12)
- # graphql (5)
- # juxt (10)
- # kaocha (20)
- # lumo (1)
- # off-topic (27)
- # pedestal (4)
- # reitit (2)
- # shadow-cljs (115)
- # spacemacs (4)
- # sql (74)
- # tools-deps (79)
- # vim (15)
- # xtdb (2)
Just fyi on kind of a tangent, core.rrb-vector is a Clojure contrib and the only build officially supported for those for build and deploy is the pom.xml - that has to be the primary
Understood.
it's ok for it to also have a deps.edn
and the tool for variant classpaths is aliases
But the pom.xml is a no-op for ClojureScript, isn't it?
oh, maybe not.
we have other contrib libs that build a single jar usable from either
data.xml, tools.reader, etc
I guess the pom.xml controls what ClojureScript source files are bundled up in there.
(tools.cli is pure .cljc
so it may not be a good example for you)
the trickiest part of clj/cljs contribs is testing and probably data.xml is the most advanced example out there
I will take a look at data.xml more carefully. I know pretty much all contribs do automated build and at least a subset of their tests automated with results on http://build.clojure.org. Do you know if any of them build and test ClojureScript code?
Ah, I see in the console log for data.xml that it does run some cljs tests using nashorn JavaScript runtime.
I should have a look at that too since the Maven build for tools.cli
only does clj testing, and I do cljs testing manually via deps.edn
...
those are the main ones I can think of that do cljs testing
"building" is really just including the cljs in the jar so not really a big deal, a bunch of contribs do that
in a lib like core.async there is a manual cljs test process that we run by hand, but it's not part of ci
So that is a great lead-in to what the pom.xml should ideally do (i.e. automate ClojureScript as well as Clojure tests), and I can look into that. Definitely nicer with a working example to start from.
As far as deps.edn file goes, would it be bad to have one, if its contents conflict with what pom.xml says?
no, not bad
many of the contribs also have project.clj files
deps.edn in a Maven-deployed JAR file should either (a) not be in the JAR, or (b) ignored by tools.deps, Maven, etc. even if one is in there?
I don't think it would be in the jar file
and it would be ignored by Maven
there are plenty of examples to check -a bunch have deps.edn files
tools.deps won't ignore it but presumably that's the point
if this gets too into the weeds on contrib, I would move it to #clojure-dev
Understood. If I haven't exhausted you with questions yet, is it short to explain what happens when tools.deps follows a dependency to a git repo, and that git repo has both pom.xml and deps.edn files?
If that is involved, no worries, I can wait.
(or experiment)
deps.edn is first
that's why I said it matters to tools.dep
thx. Keeping some notes separate from here for future reference.
@andy.fingerhut When building JARs, you're mostly just going to get src
and the META-INF
stuff (which includes a pom.xml
file) but nothing else from the repo (so no deps.edn
file).
When you depend on a JAR, the transitive dependencies are figured out from that embedded pom.xml
file (as I found out recently with depstar
!).
When you depend on a git or local repo, tools.deps
will use deps.edn
if present else pom.xml
. If neither are present, you can tell tools.deps
to "assume" deps.edn
(and it treats the absence as an empty {}
).
:deps/manifest :deps
Hey, when using tools.deps on a git dependency (which is a tools.deps project itself as well), can I load an alias of this dependency?
The use-case is: I want to dynamically load a project using tools.deps+dynpath (up to this point I got it running), access its test/
folder and run the tests.
No specific project yet, just trying some ideas.
no, not supported
but something under consideration
I think that could be solved by adding paths and deps with resolve-deps
and make-classpath
then.
If I got it right, then calling (make-classpath {...} ["test"] nil)
could allow that, right?
need more words to understand what you mean
what is "that" and "it"?
My intent of being able to run the tests from a dependency I pull dynamically as explained in the use case above.
then, yes that should work
you probably want to also include the source paths though I would assume
like ["src" "test"]
Can someone here help me to understand how I can rebuild/re-install a local dependency without quitting and restarting Spacemacs/Cider? I was originally declaring a Git dependency and then I changed my deps.edn file so that the dependency was to a local path. That is, my deps.edn started out as {:deps github-myorg/mylib {:git/url "
and changed to {:deps mylib {:local/root "/path/to/root/of/mylib"}}
.
you'll have to restart your repl to pick that up
thanks @alexmiller. I was thinking that would be necessary, but was hoping not
I have a project that depends on a library A via :local/root
. Library A depends on com.google.cloud/google-cloud-monitoring
. google-cloud-monitoring depends on commons-logging
. In library A, I have :exclusions [commons-logging]
set on com.google.cloud/google-cloud-monitoring
. When I run clj -Stree
in my top level project, I still get commons-logging/commons-logging
in the tree. If I run clj -Stree
in library A, I also get commons-logging
. Any idea what is going on here?
@kenny commons-logging
is used by a lot of things -- perhaps something else is bringing it in?
where do you see it in the tree?
did you try :exclusions [commons-logging/commons-logging]
?
I wonder if there's a non-canonicalized matching canonicalized somewhere
com.google.cloud/google-cloud-monitoring 1.78.0
javax.annotation/javax.annotation-api 1.3.2
com.google.cloud/google-cloud-core-grpc 1.78.0
com.google.auth/google-auth-library-credentials 0.16.1
io.grpc/grpc-protobuf 1.21.0
io.grpc/grpc-protobuf-lite 1.21.0
com.google.api/gax-grpc 1.45.0
io.grpc/grpc-alts 1.21.0
org.apache.commons/commons-lang3 3.5
io.grpc/grpc-grpclb 1.21.0
com.google.protobuf/protobuf-java 3.7.1
io.grpc/grpc-stub 1.21.0
com.google.api.grpc/proto-google-cloud-monitoring-v3 1.60.0
com.google.cloud/google-cloud-core 1.78.0
com.google.api.grpc/proto-google-iam-v1 0.12.0
com.google.protobuf/protobuf-java-util 3.7.1
com.google.api/api-common 1.8.1
com.google.http-client/google-http-client 1.30.1
com.google.j2objc/j2objc-annotations 1.3
io.opencensus/opencensus-contrib-http-util 0.21.0
org.apache.httpcomponents/httpclient 4.5.8
org.apache.httpcomponents/httpcore 4.4.11
commons-logging/commons-logging 1.2
Commenting google-cloud-monitoring shows another dep bringing it in. I guess I can follow the trail.
Gosh, I wonder how many other places have an exclusion that isn't qualified and it should be :thinking_face:
yeah, the code doesn't canonicalize the exclusions
Yeah, that’s a known issue
I have a plan to fix it but it’s a pain
Yes, have thought about it some
Generally you have most stuff in local repo already so I don’t find it critical