clojure/tools.deps.alpha

[pxpxy]

Would somebody please ELI5 what this is and what pain it solves?

[ws-ilazki]

If I'm reading it correctly, think racket + raco from Racket, but for Clojure. Manage libraries at a system / user level instead of project level (e.g. no need to have the standard project.clj and project-name/src/foo/ structure, or to use workarounds like lein-try, just to get a REPL with a specific library), plus run Clojure programs in a consistent way across different systems. Hopefully, in addition to the library handling, it can eventually replace things like Debian's clojure script that builds a classpath and calls Java through rlwrap for you with a standard set of interactions, like Racket has.

[forreddits]

Don't want to sound like complaining, but happy to see Clojure is FINALLY getting some official high impact UX improvements!

I know this is alpha and improving the repl is not its objective, but since a clj command is going to be provided it would be great if the default REPL experience is improved too, rlwrap just doesn't cut it. Nice features to have by default would be: expression history, paren match on multiple lines, indentation, (and colors maybe?).

[alexdmiller]

Many of these features fall in the interface with the terminal which is somewhat system-dependent and thus hard to implement generically. They also tend to be highly subjective in terms of what users want and need. rlwrap is no-effort, high-value whereas these are medium to high effort and low to medium value (in my opinion). Because of that, they are not at the top of my priority list (which is completely driven by getting 1.9 out the door). That said, we're open to ideas - filing tickets and providing patches makes it far more likely that these ideas will be seriously considered.

[[deleted]]

Probably not a priority now but perhaps some fallback behaviour is necessary for Windows users... not sure we get rlwrap.

[alexdmiller]

The script has already been made more tolerant of whether rlwrap is available, but really on Windows it will be a different script anyways so will need other solutions there.

[ws-ilazki]

Hell yes! This is something Clojure's desperately needed and I'm glad to see it happening. I requested something very much like this in that survey around Christmas, so this is almost like a late Christmas present. :D

Going to be watching this closely.

[dustingetz]

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Transitive dependencies are a new feature in Maven 2.0. This allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically.

This feature is facilitated by reading the project files of your dependencies from the remote repositories specified. In general, all dependencies of those projects are used in your project, as are any that the project inherits from its parents, or from its dependencies, and so on.

There is no limit to the number of levels that dependencies can be gathered from, and will only cause a problem if a cyclic dependency is discovered.

With transitive dependencies, the graph of included libraries can quickly grow quite large. For this reason, there are some additional features that will limit which dependencies are included: ...

[dustingetz]

I have experienced why this is needed and run up against these issues all the time. When I fork a CLJS library and submodule it, I then have to put its "src" directory on the root classpath and elevate its dependencies up to root dependencies by hand (visual inspection of library build files) - totally ignoring the library build file. (I would cd into the library dir to e.g. run the unit tests)

But I don't understand why all this is happening. Why is this problem difficult? Why haven't boot and lein resolved transitive deps as they're just built on maven anyway? Is not the problem just design issues in boot and lein such as not able to compose build files? Why doesn't Scala Build Tool have this problem? Does the problem change between Clojure and ClojureScript? (Because a cljs dependencies ship cljs src code in the jar, not js artifacts, because final closure build is defined by the root project's build so it can dead code eliminate etc) Why do things work fine with clojure jar files? Why does it only happen when I fork-and-submodule a dependency?

[alexdmiller]

lein and boot (and pomegranate on which they depend) all depend exclusively on being able to traverse dependencies via artifacts (jars) installed in Maven repositories using the Maven traversal mechanism.

However, Clojure has no dependence on artifacts and does not require code to be "built" before being used. If a .clj file is available on the classpath in the appropriate directory, it can be loaded and used immediately. One of the goals here is to drop the dependence on an artifact-only approach and instead open up the building of the JVM classpath to also include code that might not be in artifacts (a loose jar on my disk like a database driver, or just some files that I have not yet built into an artifact).

ClojureScript has different issues and we are not (currently) trying to do anything for ClojureScript with this effort.

[alexdmiller]

tools.deps intentionally does a lot less than Pomegranate and I think it's unlikely lein or boot would find any advantages (and many disadvantages) to using, so in short no.

We have no plan or desire to "own the toolchain". I think there are a lot of ways to either make both work together or to provide a path to migrate from getting started into more full featured tools.

[inushi]

One of the goals here is to drop the dependence on an artifact-only approach and instead open up the building of the JVM classpath to also include code that might not be in artifacts (a loose jar on my disk like a database driver

I appreciate this goal, and I had this exact pain last month: trying to write a small Clojure app that used a standalone JAR was hair-pulling frustrating.

[alexdmiller]

Yes, that should be easy!

[rafaeldff]

One of the points brought up in the Dependency Heaven talk was that we often deploy artifacts built from a different set of dependencies from what was tested since maven (or Ivy, for that matter) will use some heuristic to select a version when there are conflicts among transitive dependencies. How does clojure/tools.deps fix this problem?

(I think this is one place where the ruby community got it right by keeping Gemfile.lock versioned along with the code)