Unexpected side effect of gitlibs with "optional" namespaces, e.g. for myapp.ns.spec. tools.namespace will try and load the namespace regardless. This is also frustrating for :local/root dependencies, where I actually want to be able to refresh and work on both in parallel, but not necessarily on the specs.

This is similar to what clojure.core goes through I suppose.

I'm doing something derp-y here - can anyone halp - what have I missed out?

clj -Sdeps '{cheshire {:mvn/version "5.8.1"}}'
Clojure 1.9.0
user=> (require '[cheshire.core :as json])
FileNotFoundException Could not locate cheshire/core__init.class or cheshire/core.clj on classpath.  clojure.lang.RT.load (RT.java:463)

clj -Sdeps '{:deps {cheshire {:mvn/version "5.8.1"}}}'

^^ missed :deps layer

ah awesome! Thanks

so excited using the cli for the first time

I’ve been thinking about adding a warning as this is the nth time someone has asked a question like this

(inc n)

haha so yup I can't read but at least it's not just me

warning++

so nice just to get a quick clojure repl to prod this json object - I never can remember how to get jq to do what I want.

Yeah, I've been using clj for ages and I still do this, omitting the :deps layer! Probably at least once a day.

Another warning that could prove useful is if you omit the :mvn/version layer as in

{:deps {cheshire "5.8.1"}}

You do get an error for that -- but it's a bit obscure.

Ahh, cool

Error building classpath. Coordinate type  not loaded for library cheshire/cheshire in coordinate "5.8.1"

(and, yeah, I do that all the time too!)

Sounds like a need for some kind of tool that allows you to write specifications for data?

Yeah, one that is in alpha 🙂

I’ve never typoed the maven thing, but it could be I’m just editing an existing file with plenty of examples.

or perhaps a lint-like tool that has custom non-spec code that looks for and warns about data structures that look like they may be mistakes...

FYI, a transcript of Alex Miller's "Dependency Heaven" talk is now available here: https://github.com/matthiasn/talk-transcripts/blob/master/Miller_Alex/DependencyHeaven.md

We've made a lot of progress in this last week on moving from Boot to clj/`deps.edn` for our monorepo.

The issues with relative paths in :local/root has meant we have to have everything "side by side" in one part of the repo.

And we found we really needed a baseline deps.edn (in the project) and a per-subproject deps.edn (for each subproject in the repo).

So we ended up having a dummy subproject and pointing CLJ_CONFIG at that folder, so we can have all our "pinned" versions in :override-deps in an alias that every command has to use

CLJ_CONFIG=../versions clj -A:defaults:other:aliases

We have a small "build" tools subproject with a bunch of -main entry points for various tasks and we bring it in with aliases (in ../versions/deps.edn).

We'll probably have a couple of shell scripts to provide some sugar over those invocations but we've got nREPL capabilities, test, build a JAR, run migrations (SQL/data) all up and running with "just" clj and a few aliases. I need to convert two more pieces this week and we'll be close to just removing Boot from our pipeline.

hey with the new tools.deps i’m tooling around with a local jar file via the :local/root "/path/to/jar", but changes to the jar don’t seem to be reflected in the repl session. what do i have to do to (reload) or re-require after changing the jar so that the latest code is around in the repl?

That sounds like a plain ol' REPL workflow issue and you'd need to tell Clojure to reload namespaces from that JAR, regardless of which tool you were using.

Mind you, if you're rebuilding the JAR locally, why not point :local/root at the source code instead and remove the JAR step?

(you'll still need to tell Clojure to reload the code -- after all, the classpath is not changing and Clojure doesn't know to re-read files on the classpath unless you tell it to)

> reload namespaces from that JAR is that a good old (require '[foo.bar]) again?

@lwhorton (require '[foo.bar] :reload)

@seancorfield what layout did you have before?

@dominicm We had a top-level deps.edn (equivalent) and our misc. build tooling was in a completely separate folder

build/
  <tooling here>
clojure/
  deps.edn equivalent
  subproject-a/
    deps.edn
  subproject-b/
    deps.edn
  ...

Now we have

build/
  <wrapper shell script>
clojure/
  build/
    deps.edn
    build/dev-related Clojure code
  versions/
    deps.edn -- pinned versions and aliases
  subproject-a/
    deps.edn
  subproject-b/
    deps.edn

@seancorfield not super different then. Interesting solution using CLJ_CONFIG. Hard to get people to set that up, but not a problem in a smaller team though.

That's why we have a wrapper shell script 🙂

The shell script is basically build task subproject and it maps mostly onto

(cd path/to/<subproject>; CLJ_CONFIG=../versions clojure -A:defaults:<task>)

build nrepl datamapper or build test environment or build migrate sql etc

@seancorfield that doesn't seem very amenable to cursive or ciders jack in? How are you editing?

Well, I'm using Atom/ProtoREPL which doesn't support clj in any useful way and my colleague who uses Emacs/CIDER always starts his REPLs by hand and then connects to it via CIDER...

Because of the whole CLJ_CONFIG=../versions clojure -A:defaults thing, it's a pain to configure tools to start clj-repls that way anyway.

Yeah. It is as a result of that 🙂. You could restore that functionality by automating some kind of alias merging across your deps.edn files.

(This is something I expect I will end up writing, but I'm still fiddling with ways to avoid it)

You'd either need to have support for multiple deps.edn files in a clj command or your user deps.edn file would need everything we have in versions/deps.edn tho'... (if you mean to remove CLJ_CONFIG=../versions from the command itself)

Either way, not a problem for the sort of usage we have/need.

I understand. I was looking to you for a silver bullet, as I'm currently getting Edge more & more tools.depsy.

There are no silver bullets (tm)!

I can feel Fred Brooks channeling through you

What are your views on bronze bullets? 🙂

@seancorfield I’d be curious what you think of https://github.com/arrdem/katamari - I just got it to the point of being able to build classpaths, uberjar and self-host last night. It’s designed to solve the sorts of many targets and shared configuration in a single monorepo friction you’re encountering as I hit them too in my first pass at deps for our monorepo.

Will take a look. Thanks @arrdem

It’s extremely pre-alpha and currently extremely under-documented, but I’m happy to answer questions and will be trying to clean it up as I go.