Fork me on GitHub

Would love for us to swallow that frog and just settle on one format to rule them all. I'd gladly give up my personal formatting preferences in exchange for not having to care about this ever again :)


If @bozhidar and @cfleming band together and settle on a zformat formatting style, that’s a significant portion of the market


Make it opt-in and apply on save


We’re considering introducing Clojure to an existing team – not having to argue about formatting would be huge — zprint looks fantastic, with native-image support so could even be run on a github pre-commit hook.


I think people quite quickly get the whole paredit/parinfer concept, where the editor prevents you from creating an improperly delimited program … it doesn't seem a fair stretch to also prevent you from ever creating an improperly indented program


I’m definitely all for structured editing; a classic example of a really good one was Diva Scheme for PLT Scheme (now Racket): You need a mode to disable them temporarily though e.g. when resolving a merge.


I'm trying out parinfer and am irritated that I seem able to hit "tab" and move blocks of code around to create valid but aesthetically awful code (probably some config thing I borked). I'd love for it to be impossible to write untidy code, like making it physically impossible to create:


dangling paren:

  (some-stuff "test")
or have two newlines between def:
(def this "thing")

(def other "thing")
… etc


Parinfer + zprint could be quite great for beginners...


OTOH, I tried Parinfer via Nightcode — I knew how to write Clojure code in spacemacs via Cider, which doesn’t try to do too much — but parinfer messed me up quite a lot — it tried to be helpful but got in my way.


have you tried it since smart mode was added?


I need to find how to integrate with spacemacs and evil-mode, but will try again…


It helps a beginner to be able to balance forms manually, esp. if you have a linter that will point out possible problems, and a formatter that would take stylistic decisions away from you. Parinfer might be useful once you make relatively few mistakes when coding Clojure.


Parinfer is a little more loose, I agree. I think we could go a step further and have editors that totally precluded interim mistakes at all. Like: trying to add a third argument to a 2-arity function. Why do we let you type that in? Why do we let you type in something that is highly likely knowable at the reader level to be invalid, such as transposing the arguments to map – i.e. putting something that doesn't support IFn as the first argument?


I realize the dynamic nature makes some things hard to guarantee, but even though I'd say I'm a journeyman Clojure programmer, I would still appreciate the help. It's like type checking but while you type, not when you compile.


The UX for that is extremely hard to get right though — when I type a character, I expect it to show up in my buffer. If the editor puts a squiggly line later, then I know something’s wrong and I can learn something from it.


It need not be "can't type the key" levels of strictness, more like how we flag unbalanced parens today … "this is for sure going to barf". Ideally unbalanced parens become physically impossible, while messing up arguments graduates to being detected in the editor buffer rather than runtime or at compilation


I think we also have opportunity (I realize this is drifting off tools.deps but ya'll are an erudite bunch) for hinting, for instance, when I type (let [[foo bar] some-thing] …) I occasionally pass in something non-seqable as some-thing and invariably it takes me a few minutes to reverse engineer the cryptic error message and wth I did to cause it. Just flagging in the editor "reminder: some-thing now has to be seqable!" could be quite interesting …


Plus some static analysis


This should probably get moved over to #editors though.

👍 4

Yes, I recall this whizzing past at some point. I'll take another look


having trouble figuring out what the correct coordinate would be to use a local jar (datomic-pro), anyone doing this?


@mgrbyte :local/root pointed at the jar


that's what I've tried. doesn't work for me. I have:

:deps {
    com.datomic/datomic.api {:local/root "/home/matt/datomic-pro/datomic-pro-0.9.5697/datomic-pro-0.9.5697.jar"}


@mgrbyte I may have crossed wires, just to check, can you try :deps/root instead?


It's definitely :local/root in the map in the docs


ah, you're having an issue with that working 😄


@mgrbyte I'm not sure I understand, what is the problem? 🙂


clj works, but requiring the dep doesn't


Clojure 1.9.0
user=> (require '[datomic.api])
ClassNotFoundException org.fressian.handlers.IWriteHandlerLookup (


I'm using the very same jar in a lein project, which works fine.


installed locally via bin/maven-install in the datomic-pro distro (same path as the jar in the deps I listed above)


nm, think I see what's going on here


datomic pro has a pom.xml with a bunch of deps in it. can't just use that jar, need all the deps in "./lib" from the distro too.

Alex Miller (Clojure team)12:06:59

The latest tools.deps should actually read the pom inside the jar and load those for you

Alex Miller (Clojure team)12:06:24

Make sure you are on latest clj tool


thanks, will try that now


Is there any reason to prefer to doing that than using bin/maven-install and using the mvn/version w/datomic-pro?

Alex Miller (Clojure team)12:06:53

you can do either. you can also use the clj support to load the pro jar from your authenticated s3 datomic repo

👍 4

I thought it might be that.


You should be able to set :local/root to the dir with the pom.xml in, but not certain.


nearly, fails with some dep. Not a problem tho, can just use :mvn/version of the local install


Quick question.. does tools.deps expose a function to add to classpath? I couldn't find anything from the documents but I would also like to avoid adding pomegranate or lucidity.package..


@ingvij I think it’s called add-lib


Not there as of latest published version..


I see.. So that can change until I actually can rely upon..


I'll wait then.. not in a hurry for that though


@alexmiller I was going to start thinking about add-lib in the context of find-deps. I could have users do this: (-> "clojure cache" find-deps.core/deps


or I could provide a fn inside find-deps.core that invokes add-lib for you. right now I'd have to depend on your add-lib branch, so I was hesitant to bake that in quite yet

Alex Miller (Clojure team)19:06:14

yeah, I wouldn’t do that yet


cool, I might limit integration to some notes in the readme for the time being. I can't wait until we have a workflow where I can seamlessly add deps without restarting anything :)


@hagmonk Have you ever tried alembic?


@cfleming I have not ... Googling ...


fascinating, this would have been nice to have :)

Alex Miller (Clojure team)21:06:24

note that the tools.deps add-lib is a little different than the other existing things out there

Alex Miller (Clojure team)21:06:06

it’s not just blindly adding a lib (and/or it’s transitive deps), it’s actually detecting which things you don’t already have, resolving lib versions, and updating an internal map of loaded libs and versions


and obviously it can work on more than just jars

Alex Miller (Clojure team)21:06:32

that too, all the standard tools.deps differences


Alembic also does the detection of existing things you have installed, although it doesn’t use a map, it uses the list of things in your existing classloader.

Alex Miller (Clojure team)22:06:23

The tools.deps impl falls back to that


I have some crazy ideas in this space - I feel like we can go a lot further than just adding the libs. For find-deps I want to analyze clj code on github to build "recommended deps" based on the one you're importing. For instance, reagent and re-frame often go together. Intelligently figuring out exclusions could be another one.


How would I do a local build and deploy of tools.deps.alpha?

Alex Miller (Clojure team)22:06:46

That will use the current snapshot version in the pom

👍 4

Debugging some issues using tools.deps.alpha on Windows, and pretty much a noob with aether. Why would return nil?

Alex Miller (Clojure team)23:06:45

Dunno, not sure why windows would be special

Alex Miller (Clojure team)23:06:13

I’ve got ports of clj using tdeps on Windows that work


Hmmm, that's what I would have guessed. It's being called by lein-tools-deps, so maybe the problem originates farther up the call stack.


@dave.dixon Perhaps because lein-tools-deps calls (clojure-env) in t.d.a. and that shells out to call clojure to get the list of deps.edn files to consume -- and I would expect that command to fail on Windows (until we have a Windows port of the clj/`clojure` shell scripts).


(so maybe it doesn't have the environment that make-system requires)


@seancorfield That I have working, albeit locally hacked. I'll double-check that the right info is getting scraped.


I nearly said "...unless you have a mocked up version of clojure on Windows!" 🙂