Fork me on GitHub
#tools-deps
<
2019-11-08
>
plexus08:11:24

@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

vlaaad11:11:05

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.

dominicm11:11:44

Using sed for xml was hard :) Garamond works okay in this space.

dominicm11:11:25

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.

Drew Verlee15:11:31

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?

dominicm15:11:22

Although a deps.edn is probably easier

Drew Verlee15:11:19

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

Alex Miller (Clojure team)15:11:36

it doesn't contain integrant twice

Alex Miller (Clojure team)15:11:50

it contains two source directories from within integrant (src and src/main/clojure)

Alex Miller (Clojure team)15:11:05

the latter doesn't exist, so no worries

Alex Miller (Clojure team)15:11:27

(that's the standard Maven source path for Clojure source files)

Drew Verlee15:11:55

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?

Alex Miller (Clojure team)15:11:26

I don't know what that is

Alex Miller (Clojure team)15:11:56

it's certainly not an issue to the jvm to have a classpath entry that doesn't exist

Alex Miller (Clojure team)15:11:28

which I assume is why that's a warning

Drew Verlee15:11:11

thats the output from running depstar https://clojars.org/seancorfield/depstar. Right, makes sense. thanks

seancorfield19:11:52

@drewverlee Integrant doesn't have a deps.edn file and that path indicates you are depending on it via a :git/url?

seancorfield19:11:41

Ah, with a pom.xml file. Got it.

seancorfield19:11:30

@alexmiller Does t.d.a. assume src/main/clojure when it sees a POM file in a Git dep?

lread19:11:07

hello! I am wondering, should :override-deps affect the pom.xml generated/updated by -Spom?

seancorfield19:11:47

@lee If you specify an alias that brings in that override...

seancorfield19:11:43

(at least, that's why I would expect -- I've never tried it)

lread19:11:51

Yep, I am specifying the alias and it does not affect pom.xml in my little test. Could be I botched something.

seancorfield19:11:55

Based on a quick test, it doesn't seem to.

seancorfield19:11:17

(! 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

seancorfield19:11:42

But clj -A:old -Spom produces a pom.xml that uses 1.10.1 not 1.9.0

lread19:11:38

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

seancorfield19:11:12

I'd say that's a bug. @alexmiller?

Alex Miller (Clojure team)20:11:47

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

Alex Miller (Clojure team)20:11:02

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?

seancorfield20:11:35

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:

Alex Miller (Clojure team)21:11:54

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

lread21:11:34

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?

lread21:11:15

Also do you want me to raise an issue for this? Or is it via ask clojure now?

Alex Miller (Clojure team)21:11:31

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

Alex Miller (Clojure team)21:11:09

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

Alex Miller (Clojure team)21:11:49

and that's what I'm matching in the update. inevitably, all decisions here will be wrong for someone.

lread21:11:37

true enough! So long as behavior is consistent and easy to understand, it works for me! (for what that's worth!)

lread22:11:42

cool, thanks alex!