This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-08
Channels
- # adventofcode (9)
- # announcements (5)
- # babashka (3)
- # beginners (46)
- # calva (21)
- # cider (15)
- # clj-kondo (20)
- # cljs-dev (57)
- # cljsrn (10)
- # clojure (147)
- # clojure-dev (6)
- # clojure-europe (3)
- # clojure-france (2)
- # clojure-italy (8)
- # clojure-nl (18)
- # clojure-norway (5)
- # clojure-spec (16)
- # clojure-uk (63)
- # clojuredesign-podcast (7)
- # clojurescript (65)
- # clojurex (42)
- # cursive (12)
- # datomic (10)
- # fulcro (47)
- # graalvm (102)
- # graphql (2)
- # jobs (5)
- # joker (12)
- # off-topic (33)
- # pedestal (6)
- # re-frame (6)
- # reagent (8)
- # reitit (6)
- # remote-jobs (4)
- # rewrite-clj (10)
- # shadow-cljs (86)
- # sql (45)
- # testing (4)
- # tools-deps (43)
- # vim (8)
- # xtdb (3)
@drewverlee maybe obvious but worth noting, if you control the repo you can just lein pom
and check in the pom.xml
next to the project.clj
I'm starting to feel that both lein pom
and clj -Spom
is a case of easy over simple. There is a dependency format — pom, that has many different stuff in it. It's much more than list of deps + artifact + version, but tools like lein pom
and clj -Spom
give only the most common baseline, which might cover some percentage of use cases, but whenever I want to publish a library, I realize that that's not enough. I need to specify developer/license information. I need to specify version as tag in scm information. Someone else will want to specify git sha instead of tag in scm. Dependencies I use during development might go to different profiles, with different activation rules, so what lein
/`clj` provides to update dependency list might even be wrong.
I guess ideally I want to produce pom from code I write, aided with information from tools-deps/git and some helpers to generate xml from data, but ultimately be the one who decides what goes where. I guess where is no such tool yet because you can just check in pom.xml
and update it with scripts using sed or whatever, and that's good enough.
I think it's okay to say that pom.xml is a combination of data sources into one. I personally would not want to manage the tag/version stuff as I'd definitely get it wrong.
Interesting. So assuming no plugin modifies the deps. then its as easy as generating a pom for say a project like: https://github.com/weavejester/integrant?
what would the output of clj -Spath | grep integrant
containing integrant twice imply? Im trying to undertsand a build error.
/home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src:/home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src/main/clojure
it doesn't contain integrant twice
it contains two source directories from within integrant (src and src/main/clojure)
the latter doesn't exist, so no worries
(that's the standard Maven source path for Clojure source files)
thanks alex. So {:warning "could not find classpath entry", :path "/home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src/main/clojure"}
isn't indicating something is wrong with my build? its because ____ produces that path and then a later tool can't find the entry on it?
I don't know what that is
where do you see it?
it's certainly not an issue to the jvm to have a classpath entry that doesn't exist
which I assume is why that's a warning
thats the output from running depstar https://clojars.org/seancorfield/depstar. Right, makes sense. thanks
@drewverlee Integrant doesn't have a deps.edn
file and that path indicates you are depending on it via a :git/url
?
It's a fork.
Ah, with a pom.xml
file. Got it.
@alexmiller Does t.d.a. assume src/main/clojure
when it sees a POM file in a Git dep?
hello! I am wondering, should :override-deps
affect the pom.xml
generated/updated by -Spom
?
@lee If you specify an alias that brings in that override...
(at least, that's why I would expect -- I've never tried it)
Yep, I am specifying the alias and it does not affect pom.xml
in my little test. Could be I botched something.
Based on a quick test, it doesn't seem to.
(! 815)-> cat deps.edn
{:paths ["resources" "src"]
:deps {org.clojure/clojure {:mvn/version "1.10.1"}}
:aliases
{:test {:extra-paths ["test"]
:extra-deps {org.clojure/test.check {:mvn/version "0.10.0"}}}
:old {:override-deps {org.clojure/clojure {:mvn/version "1.9.0"}}}
:runner
{:extra-deps {com.cognitect/test-runner
{:git/url ""
:sha "76568540e7f40268ad2b646110f237a60295fa3c"}}
:main-opts ["-m" "cognitect.test-runner"
"-d" "test"]}}}
Fri Nov 08 11:33:00
(sean)-(jobs:0)-(~/clojure/pommy.example)
(! 816)-> clj -A:old
Clojure 1.9.0
user=> ^D
But clj -A:old -Spom
produces a pom.xml
that uses 1.10.1 not 1.9.0
thanks sean! -Stree behaves as expected:
> clj -A:old -Stree
org.clojure/clojure 1.9.0
org.clojure/spec.alpha 0.1.143
org.clojure/core.specs.alpha 0.1.24
I'd say that's a bug. @alexmiller?
this is trickier than it looks. I may actually have broken it in my recent set of changes. the tricky part is that the aliases are about resolving transitive deps and building a classpath, but you're not actually building a classpath here, you're just making a different manifest file
so if you supplied override-deps for some lib N levels down, what does that mean? do you add it to the root deps to get the same effect? or just ignore it?
I would certainly expect the dependencies in pom.xml
to match the top-level deps in -Stree
output but I agree that it's really hard to decide what the transitive dependencies should be. Hmm :thinking_face:
I used to do a bunch of fiddly logic to half apply stuff from the aliases during gen, but I stopped doing that in my last round of changes and just reused the same core from making classpaths, but did not properly take that all the way
Forgive my naive question @alexmiller, I'm sure you've put much thought into this. Wouldn't adding the override of the transitive dep to the root deps give the intended result?
I've actually fixed it locally, so no need to do anything. I'll probably log a jira just for tracking before I commit it
on the transitive deps, the decision I had made in the past was to only modify the root deps and not include overrides in transitive deps
and that's what I'm matching in the update. inevitably, all decisions here will be wrong for someone.
true enough! So long as behavior is consistent and easy to understand, it works for me! (for what that's worth!)
@lee https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-143, fix in master but not released