Fork me on GitHub
#clojure-dev
<
2017-10-31
>
seancorfield18:10:05

@alexmiller I upgraded clj/clojure via brew and now I get this error from both the clj and the clojure commands:

Error building classpath. No method in multimethod 'dep-id' for dispatch value: null
Pointers on debugging it?

ghadi18:10:05

@seancorfield move away your ~/.clojure/deps.edn and it will get autogenned the next time you run clj

alexmiller18:10:20

yeah, there was a change in the format of the deps.edn file

alexmiller18:10:34

if you have a local deps.edn file you will need to update it as well

seancorfield18:10:52

@ghadi Thanks. Yeah, that fixed it. @alexmiller I'll have to see which of my test projects have an old deps.edn file and figure out what I need to change.

alexmiller18:10:09

the web site stuff is all up to date

alexmiller18:10:21

let me know if you need an eye, I can probably spot things quickly

seancorfield18:10:32

Looks like :type :mvn :version "x.y.z" became :mvn/version "x.y.z" and the :providers also flattened things to use qualified keys?

alexmiller18:10:56

:providers isn’t even there

alexmiller18:10:08

we just pulled the keys up and namespaced them

alexmiller18:10:29

I’m hoping we are largely done with the format changes now. would like to leave alpha and commit to what we have soonish.

seancorfield18:10:12

:thumbsup::skin-tone-2:

seancorfield18:10:18

OK, weirdness with multiple aliases. I have aliases for :1.8 and :bench (following the Guide examples) and when I specify multiple -R values, I don't get the expected result...

seancorfield18:10:32

:aliases {
    :1.8 {:override-deps {org.clojure/clojure {:mvn/version "1.8.0"}}}
    :1.9 {:override-deps {org.clojure/clojure {:mvn/version "1.9.0-beta4"}}}
    :master {:override-deps {org.clojure/clojure {:mvn/version "1.9.0-master-SNAPSHOT"}}}
    :bench {:extra-deps {criterium {:mvn/version "0.4.4"}}}
  ;;   :deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "0.2.167"}}}
    :test {:extra-paths ["test"]}
  }

seancorfield18:10:59

(! 599)-> clj -R:1.8
Clojure 1.8.0
user=> ^D
(! 600)-> clj -R:1.8,bench
Clojure 1.9.0-beta3
user=> ^D

seancorfield18:10:05

That doesn't seem to pull in :bench either

(! 605)-> clj -R:bench,1.8
Clojure 1.9.0-beta3
user=> (require 'criterium.core)
FileNotFoundException Could not locate criterium/core__init.class or criterium/core.clj on classpath.  clojure.lang.RT.load (RT.java:463)

seancorfield18:10:22

(! 604)-> clj -R:bench
Clojure 1.9.0-beta3
user=> (require 'criterium.core)
nil

seancorfield18:10:36

Am I doing something wrong here?

seancorfield19:10:39

From the Guide: Invoke: clj -R:bench,1.9

alexmiller19:10:26

yeah, that’s wrong

alexmiller19:10:30

should be -R:bench:1.9

alexmiller19:10:51

concatenated keywords

alexmiller19:10:11

fixed and redeploying, sorry that one snuck through

seancorfield19:10:00

Ah, yes, that works

(! 606)-> clj -R:bench:1.8
Clojure 1.8.0
user=> (require 'criterium.core)
nil
user=> ^D

seancorfield19:10:03

Thanks. I see :lein as a possible manifest type -- "coming soon" along with :git providers? 🙂

alexmiller19:10:22

I’d prefer to outsource some of that stuff. I’ve spent some time working on pom manifests and as usual, the maven stuff is 100x harder than it should be (reading it is pretty straightforward but doing a full resolve on the pom that takes into account the full model is super annoying)

alexmiller19:10:24

for lein, I’m also not sure how easy it is to pick up a lein project.clj and actually parse it to a point of understanding its dependencies past a naive read. however, there is nothing provided (yet!) to allow for external libs to get hooked into the tools.deps invocation. That needs to happen before this can be a fully open system that people can plug into. I have an idea of how that will all happen but trying to knock off some other stuff first.

alexmiller19:10:14

much of the recent overhaul around manifests was done with an eye to the similarities between local and git projects (the latter just needing to be downloaded to somewhere first at which point the problems are identical)

alexmiller19:10:39

so again, we have the beginning of a plan in that direction

alexmiller19:10:04

this is deep vein of ideas, plenty to do :)

seancorfield19:10:43

Cool. I'll probably start to look at using tools.deps.alpha as a library to use from a Boot task to allow Boot to depend(!) on the new deps.edn machinery. I'm primarily interested because we already use (a different format of) deps.edn at work for describing our dependencies and I'd like to bring that all in line with the "standard" new approach.