Clojure Q&A - Recent questions tagged deps.edn

a) how: programmatically set REPL ‘context’ ‘prj-1 aware’? b) how: programmatically switch REPL ‘context’ ‘prj-n aware’?

Sun, 23 Feb 2025 16:56:50 +0000

Ok, regardless of editor, running clj in a directory will start a repl that has "project context" to project deps.edn in that directory, and that is the way that most Clojure developers create a connected repl.

The implication seems to be to work on a different project one must (System/exit 0) VM and start another VM using clj command to ‘create a connected repl’ to project deps.edn in a different directory? This appears to be idiomatically (colloquially) referred to as ‘restarting the REPL’ I believe?

Seems rather draconian for a dev env, let alone a lisp dev env? I thought the highly dynamic heritage of lisp replete with multiple REPLs was universally sought after? 10 years later and no multiple REPLs for clojure? Personally, I’m somewhat surprised, but maybe nobody really wants, needs or requires multiple clojure REPLs? I think multiple REPLs could be transformational in many use cases IMHO, or maybe I’m really ‘out of the loop’ no pun intended?

03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/mgwvmEnjnBoJ) several notable sub-quotes:

“I think it is important, with tooling, to have the broadest, open notion of the types of 'use cases' for Clojure, and for workflows of people using Clojure, lest you actually limit them. I hope people are able to write their languages and DSLs, test embedded control/debug consoles, design next-generation REPLs and debuggers, grab data dumps etc, all from their REPL. That's the heritage of Lisp. Many people are doing data science, languages, genetics, rule-systems etc type things with Clojure, not just web apps

But it is quite common in rich Common Lisp IDEs like Lispworks for people to have multiple listener (REPL) sessions open at the same time (against the same runtime). You can launch long running processes that produce streaming output, switch to another listener and continue interaction and development, have separate listeners for separate contexts/state/command-history etc. There's a lot to Lisp development that's not RPC.

Note multiple listeners, data inspectors and more. Maybe not the latest GUIs, but the capabilities should be a source of inspiration for any Clojure IDE.”

Previously hinted personal end goal: exploit ‘critical mass’ for a (truly) ‘dynamic’ clojure dev env, including dynamic java recompilation, namespace reloading, etc. and include at a minimum:

clojure.repl.deps
clojure.tools.build.api (clojure.tools.build)
clojure.tools.deps
clojure.tools.deps.cli.api (clojure.deps.cli)
clojure.tools.namespace
clojure.tools.tools.api (clojure.tools.tools)
GitHub - clj-commons/virgil: Recompile Java code without restarting
the REPL (https://github.com/clj-commons/virgil)
other polyglot ‘evaluation/compilation’ TBD

I also included a few tools to help come back up to speed quicker:

GitHub - nubank/morse: A graphical, interactive tool for browsing
Clojure data (https://github.com/nubank/morse)
[clj-ns-browser/clj-ns-browser "2.0.0-SNAPSHOT"] – Clojars
(https://clojars.org/clj-ns-browser/versions/2.0.0-SNAPSHOT)

Eventually will look at many ‘current projects’ including: GitHub - HumbleUI/HumbleUI: Clojure Desktop UI framework (https://github.com/HumbleUI/HumbleUI) as stated to build better apps than possible with web, AND access full power of your computer (multithreaded), wouldn’t that be convenient?

Another quote from 03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/IHoVWiJz5UIJ):

“REPL stands for something - Read, Eval, Print, Loop. It does not stand for - Eval RPC Server/Window.”

Anyway, that would be ERSW, seriously, I couldn’t agree more, a required lisp feature, for me anyway: multiple simultaneous-concurrent (multi-threaded) REPLs, I refer to as ‘Clojure Listeners’ (‘in-process’ or ‘against the same runtime’) non-socket non-nREPL non-LSP non-network non-middleware non-multi-VM based REPL approaches that support multiple simultaneous dev management ‘native VM’ approaches for polyglot projects ala GraalVM.

[SEE Multiple Clojure Listeners] (https://github.com/mgrisius/clj-mode/blob/0.9/Clojure_Listener_2025-02-23_09-02-41.jpg)

Note JavaScript Listener “JS-1” pictured. Could have python, R, ruby, or whatever language(s) available in GraalVM. ‘Clojure Listeners’ used with or without emacs, ‘regardless of editor’, in any Java VM for that matter. Could easily have multi-threaded socket-based listeners . . .

Clojure Listeners: multi-threaded, full history, type ahead, line editing, completion, pop-up menus, colorized output, colorized-balanced-brackets-([{, etc. Also working on other listener features: multi-line editing, enhanced source lookup, doc lookup, repo-artifact search, embeddable .e.g. in morse, etc. all leveraging the ‘purest clojure value chain possible’!

As previously mentioned, my basic ‘old style’ simple.bat with (~60mb) über jar simple compatibility with emacs lisp-inferior-mode works good with ‘legacy’ approach and new ‘CLI deps.edn approach’ basic use so far, both with ~1 second startup time. Zero optimization has been done thus far, e.g. GraalVM native image, etc.

My forward-looking goal & reason for asking initial question: compatibility with future clojure tool direction(s), NOT invent the next ‘technical debt’ ad hoc one-off hack. My Holy Graal: I want a fully dynamic long running VM under full clojure programmatic control.

So, the question remains: a) how to programmatically set REPL with ‘context’ for ‘project-1 aware’? b) how to programmatically switch REPL ‘context’ to ‘project-n aware’?

deps.edn support for :git/branch + :git/sha

Thu, 20 Feb 2025 06:04:47 +0000

Are there plans to add a :git/branch key for Git libs in deps.edn that works like :git/tag? In other words, Git refs (:git/branch or :git/tag) have to be paired with a Git SHA (:git/sha) to lock to a specific commit as Git refs can be updated to point to different commits.

For example:

{:deps {owner/repo {:git/url "https://github.com/owner/repo.git"
                    :git/branch "1.x"
                    :git/sha "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12"}}}

The purpose is to support projects using major version branch workflows as compared to tag + release workflows.

Major version branch workflows may be used for things like private polyrepo projects (e.g. a web service where the API specs/model, backend, and infrastructure-as-code templates are split) that don't need the additional overhead that comes with using tags + releases.

Auto-update tools like Renovate or Dependabot can use the Git ref key in a deps.edn Git lib to update its locked :git/sha.

For tag + release workflows, this may be some heuristic like semantic versioning.

For major version branch workflows, the auto-update tool needs to use something like :git/branch to:

Tie break between a given Git SHA's descendants if there's multiple.
Ignore PR branches on the tip of a given branch (e.g. ignore a PR branch that's a descendant of the tip of the main branch).

a) how to start REPL with ‘context’ for ‘project-1 aware’? b) How to switch REPL ‘context’ to ‘project-n aware’?

Mon, 17 Feb 2025 17:14:46 +0000

Been away from clojure for a while, taking a fresh look at CLI & deps tool chain current status, direction & potential work flow(s). Previously maintained linux, macOS & MS Win / WSL2 dev envs, only looking at MS Win clojure right now.

Dev env includes GraalVM JDK 23, clojure 1.12.0, emacs 27.1 with minimal (ancient) lisp-inferior-mode clj-mode (https://github.com/mgrisius/clj-mode), and Apache ant/ivy 1.10.3 for Transitive Dependency Management (TDM), classpath & java command construction. My ‘legacy’ emacs, clojure & java code are operational again.

Using basic ‘old style’ simple.bat with (~60mb) über jar simple compatibility with emacs lisp-inferior-mode with ~1 second startup time, e.g. m-x eval-expression (run-lisp “simple.bat”):
java -cp E:\dev\projects\simple\target\0.0.1.standalone.jar clojure.main

Current goals include: convert to CLI & deps tools, among others.

Installed clj-msi (Clojure 1.12.0.1501) Clojure for Windows 25.5.3460.1501, create basic project, deps.edn etc. Can use CLI from cmd.exe or powershell.exe to execute basic actions: invoke REPL, check versions, download deps, create über jar etc. Command line stuff works good!

Not sure how best to leverage CLI & deps from a basic .bat file so that the resulting REPL is ‘project aware’, e.g. sees project deps.edn, build.clj, user.clj plus ‘tools.build’ related capabilities? So far, subtle differences between CLI interactive and basic .bat cmd.exe or powershell.exe results.

As the tools.build Guide states: “We want to write this program with our favorite programming language, Clojure, and tools.build is a library of functions commonly needed for builds that can be connected together in flexible ways. Writing a build program does take a bit more code than other declarative approaches, but can be easily extended or customized far into the future, creating a build that grows with your project.”

I prefer writing clojure code over complex cross platform compatible (shell) scripts, workarounds or hacks. So, I think I want full CLI functionality to use from the REPL to avoid incidental complexity, e.g. ‘very complicated’ problems discussed in Clojure CLI Reference in ‘Quoting keys and values’ related to platform specific issues wrt cmd.exe or powershell.exe concerns. Overall goal: avoid ‘technical debt’ from ANY platform specific minutiae for ANY shell, e.g. bash/tcsh, cmd.exe, powershell.exe, or even any new emacs lisp to focus solely on investment in purest clojure value chain possible.

BTW: happily seems like there’s ‘critical mass’ for a (fairly complete) ‘dynamic’ clojure dev env with tools akin to early lisp machine (lispm) (e.g. Symbolics) ‘procedural’ style defsystem.

Re-read clojure doc a few times, no mention on how a REPL is or s/b connected (‘in-process’) in a single VM with access to a ‘project’ with ‘tools.build’ and related features enabled? Or how to switch ‘build context’ to another ‘project’. Looked at monorepo / Polylith type subprojects that use ‘with-project-root’. Might be a good fit for a ‘mega project’ but doesn’t seem like a good fit (at least to me) for disparate, scattered or loosely coupled projects. Could keep a list of target project dirs and ‘map’ specific build tool process using ‘with-project-root’?

Also mentioned in tools.build Guide: ‘Parametrized builds’ that s/b easy to use from CLI and via programmatic use to generate :dev :test :debug :deploy :install :prod :maintenance or :whatever actions or artifacts are required in conjunction with a ‘clj -T:build action-name’ approach. Seems very reasonable, if there was a repeatable initial setup or process to make project deps.edn etc. & tools.build aware at a REPL.

To summarize, it would be nice to have a minimal .bat file and/or ‘user.clj’ to enable the CLI deps experience/capabilities/tools programmatically via REPL. Am I over thinking or missing anything here? Perhaps by design or maybe it’s too early to ask for normative, idiomatic or canonical recommendations?

My initial question is a) how to start a REPL with ‘context’ that is ‘project-1 aware’? b) How to switch a REPL ‘context’ to be ‘project-n aware’?

I apologize I’m just starting out with CLI, deps.edn, tools.build, user.clj, etc. and have not absorbed many of the intricacies re required libraries, operational details, setup and intended use cases. Any suggestions would be greatly appreciated, thanks for sharing any insights!

Confusing error message on deps.edn wrong git/url dependency

Thu, 05 Dec 2024 10:17:00 +0000

When you misspell the :git/url of a git dependency (or the dep name used to infer a url) the error says :

Cloning: https://github.com/MISSPELLED-ORG-OR-REPO-PATH
Error building classpath. Unable to clone /home/user/.gitlibs/_repos/https/github.com/MISSPELLED-ORG-OR-REPO-PATH
fatal: could not read Username for 'https://github.com': terminal prompts disabled

I find the the 3 sentences confusing since they mention classpath, a local folder, username, and terminal prompts disabled.

It would be great if it more clearly can express that no repo could be found with the provided URL, or at least remove the last sentence fatal: could not read Username for 'https://github.com': terminal prompts disabled which I find misleading.

Maybe the Unable to clone could be followed by the url instead of the local folder also?

How can I ensure that a private Maven coordinate cannot be shadowed in a public repository?

Wed, 16 Oct 2024 11:08:07 +0000

Given a deps.edn file with a :mvn/repos entry for a private Maven repository and a dependency on a Maven coordinate that lives in that repository, how can I mitigate the risk of that coordinate getting shadowed / hijacked in one of the default public repositories?

Possible solutions:

Allow pinning a Maven dependency to a particular repository
Allow declaring priority order of Maven repositories (in the example scenario, the private repository would then get the highest priority and always be checked before the other ones)
Allow pinning a Maven dependency to a particular signing key and require it be signed (but looks like tools.deps currently doesn't support verifying signed artifacts?)

No way to specify Clojure version across all deps.edn files in a monorepo

Sun, 15 Sep 2024 19:46:47 +0000

Suppose you have deps.edn at the root and then a bunch of sub-directories with their own deps.edn files.

If you want to have a set of common dependencies for all of the projects, you can simply have e.g. a common directory where common/deps.edn specifies all of the common dependencies and all the rest of deps.edn files list common as one of their deps.

However, that doesn't work with org.clojure/clojure, making it implicitly special.

As I mentioned on Slack, it seems that clojure.tools.deps/root-deps brings the default top-level version of org.clojure/clojure and nothing else can override it but another top-level version.

Refresh/Reload deps.edn changes in Calva + VS Code in WSL Ubuntu

Mon, 19 Aug 2024 15:16:49 +0000

Hi, I am new to Clojure and am following this tutorial to make a Clojure API. This uses Cursive plugin in IntelliJ, but I am using Calva in VS Code.

This is my project structure:

 .
├── deps.edn
├── resources
│   └── config.edn
└── src
    └── clojure_api
        ├── config.clj
        └── core.clj

My config.clj file contents:

(ns clojure-api.config
    (:require [aero.core :as aero]
            [clojure.java.io :as io]))

(defn read-config []
  (-> "config.edn"
      (io/resource)
      (aero/read-config)))

I changed my deps.edn file to add the paths src & resources like this:

{:deps {aero/aero {:mvn/version "1.1.6"}} :path ["resources" "src"]}

while keeping the config.edn file an empty map: {}. However, I could not read the config file from read-config function in config.clj. It gave this error in Calva repl:

; Execution error (IllegalArgumentException) at aero.core/read-config-into-tagged-literal (core.cljc:194).
; Cannot open <nil> as a Reader.

The tutorial solved this error in Cursive by refreshing the project structure. I cannot seem to find any such commands in Calva. How can I update/refresh my project structure in Calva so that the deps.edn changes are reflected in the repl?

I have tried to restart the repl, reopening the folder in VS code, shuffling the resources directory around to no avail.

I could not find related answers to this problem after googling, so any help will be appreciated.

Tagged literals in Clojure CLI arguments and deps.edn

Tue, 12 Sep 2023 21:02:35 +0000

As it stands there is no way for the Clojure CLI to extend the reader with tagged literals for use within arguments or deps.edn.

I propose that some mechanism for this should be added, which can enable additional tooling to use the intended use case of putting data within aliases in deps.edn where they otherwise would be restricted by data readers.

An example of a current project which would benefit from this is Codox, which has support for regular expression based filters on namespaces to be documented, however as the default EDN reader does not include support for regular expressions, this feature is unusable.

If tagged literals support was added to the Clojure CLI, this problem could be resolved by a #jvm/regex tag or similar being added for that usecase.

If this feature is added it should also be considered what happens when a deps.edn file or argument to the CLI includes a tagged literal which is not bound in the current invocation.

There are multiple ways that support could be added to the CLI, and below I present a few of my own thoughts on the matter, but this is not a request for this to be the way that the feature is implemented, just some ideas.

Tagged literals could be added via aliases in the user deps.edn which are then used by default in all projects
Tagged literals could be specified by an environment variable, which users can then set with direnv or other tooling

Feature request for Clojure CLI: Some way to specify OS-conditional values for :local/root in deps.edn

Sat, 08 Jul 2023 12:57:54 +0000

This problem arose trying to run a Clojure project on WSL2 from a project originally built on Windoze.

The original :local/root paths started with "C:/..." but on WSL2 (running Ubuntu 22) they need to be converted to "/mnt/c/..." to run.

Manually changing them makes them work, but it's a hassle. Won't even mention source control woes.

Imagining automatic conversion rules feels dreadful, it would be better if we could simply specify OS-specific values. Maybe something like:

{some.ns/some-lib {:local/root 
                    {:local-path/windows "C:/..." 
                     :local-path/linux "/mnt/c/..." 
                     :local-path/macos "/some/other/dev/path"}}}

At runtime, the correct local-path should be selected for the value based on the OS on which the JVM is running.

Surely this can also be a problem on MacOS running Parallels, where file system integration is also tight but the Guest OS can have different values for the same paths on the Host. And knowing what these might be a priori is probably not practical, given the Cambrian explosion of Linux distributions, Windows editions, and MacOS versions. It would be the developer's responsibility to set these values based on a concrete development setup. So, IMHO, it would be enough optionally to offer some ability to provide a map with certain high-level OS options in place of a string.

It also seems obvious to me that these values will always be developer-centric and possibly subject to employer devops policies.

(Yes, this is my implementation bias, but I would gladly support any general way to handle this problem.)

Clojure CLI has a way to specify namespace to REPL like Leiningen :init-ns?

Tue, 18 Apr 2023 01:24:42 +0000

After installing https://github.com/seancorfield/deps-new I created a project with the command clojure -Tnew app :name clojure-backend and followed pedestal component guide http://pedestal.io/guides/pedestal-with-component. The repo is in: https://github.com/cloped/clojure-backend

I'm trying to achieve the same thing as I used to do on Leiningen project, start my REPL on Cursive on the namespace where the component start function is declared and call it.

Reading the nREPL doc https://nrepl.org/nrepl/usage/server.html there is a :init-ns on Leiningen, that makes this work.

After some several discussions on Clojure slack thread https://clojurians.slack.com/archives/C0744GXCJ/p1681750400843819, and many attempts to load a desired namespace on Cursive REPL and Clojure CLI we understood that this may be some functionally that could go to Clojure CLI

Colin helped me to find where this is implemented on Leiningen: https://github.com/technomancy/leiningen/blob/24fb93936133bd7fc30c393c127e9e69bb5f2392/src/leiningen/repl.clj#L175-L195

I'm wondering if this is something that makes sense to Clojure CLI. And if it is I am excited to help implement this to begin my contributions to Clojure community.

Feature request for Clojure CLI: Command to create minimal deps project

Wed, 01 Mar 2023 14:11:45 +0000

This is for onboarding newcomers, including those for whom installing additional tools is nontrivial.

From my perspective as a teacher it would be really sweet if an absolutely minimal project could be created with the CLI tools alone. "It must be done by hand or use a 3rd party tool" is an impediment to some of my students, and presumably to other newcomers. In a class setting, with students using different machines and OSes and having different backgrounds, a variety of issues that will seem trivial to developers (such as OSes that add hidden file extensions, editors that encode text, OS path issues, etc.) can produce a lot of discouraging friction.

By "absolutely minimal project" I mean a directory containing a deps.edn that contains {}, and also containing a src folder that contains a single subfolder with the same name as the top-level folder, that in turn contains a single file (might as well be called core.clj) that just contains a minimal ns expression, with a namespace name matching the folder and file names, and nothing else.

I understand that there would be a lot to think about regarding the more general question of whether the CLI tools should support more robust project creation facilities, and if so then what kinds of projects it should create, how this would be organized, etc. But my request here is for something so minimal that I hope it could be considered independently of questions concerning more general facilities. I also hope that this minimal-project-creation feature can be considered independently of the more general issues because I think it would significantly ease the onboarding of some communities of new users.

Feature Request for Clojure CLI: Treat empty deps.edn the same way as a non-existing one

Thu, 19 Jan 2023 21:48:27 +0000

When clojure is called from a directory with an empty deps.edn it exits with a non-zero value. I wonder if it could be considered to treat that situation the same as when there is no deps.edn file at all?

This would be improve the Calva Ux a great deal. Calva defaults to start clojure-lsp at activation. One activation trigger is that a Clojure file is opened. Creating a deps.edn file in VS Code will create it as an empty file which the user then can edit. When clojure-lsp starts because of the file creation, clojure is called by clojure-lsp to figure out the classpath. If the file is still empty by then, the command fails, and no clojure-lsp for the user in that session.

It gets extra important for beginners with Clojure, who we want to instruct how to create a minimal deps.edn project and use a Clojure editor to connect to the REPL. As it is now the instructions get complicated.

Set GITLIBS in deps.edn

Wed, 30 Nov 2022 15:44:50 +0000

Currently, git libs are cloned to ~/.gitlibs by default, and this can be changed with the environment variable GITLIBS. (See docs)

It would be helpful if I could set that location via an entry in the repo's deps.edn file, akin to :mvn/local-repo:

{:mvn/local-repo "local-m2" :gitlibs "gitlibs" :deps {...}}}

If this could be done, I would also appreciate it being available within an alias. This probably would require implementing the same for :mvn/local-rep first (see relevant Ask).

Programmatically connect dependencies to the maven repos that provide them

Fri, 11 Nov 2022 20:38:29 +0000

As a Clojure developer,
I want to be able to link project dependencies to the maven repos that provide them
so that a) tools that work with dependencies (e.g. nvd-clojure, clj-watson) have more first-hand information to work with, b) I can easily find out custom maven repos that are no longer used and c) get a better understanding in general of what my project is composed of.

Workaround

clj -Sdeps '{:mvn/local-repo "tmp"}' -Stree uses a custom local maven repo to force a redownload of the jars and provides a way to do the above by looking at the messages (e.g. Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.pom from central), so it can be ok in some cases.

Would you consider simplifying this process by providing a way to get that information as data? I would love to have it in clj -X:deps tree :format :edn for instance.

Support `:mvn/repos` inside an alias

Tue, 08 Nov 2022 19:08:24 +0000

This is similar to https://ask.clojure.org/index.php/11711/set-mvn-local-repo-via-alias, sorry if I should have just added a note there instead of opening another question.

:mvn/repos does not seem to work inside of an alias either -- only at the top level of deps.edn. If this is intentional, it would be a nicer experience if CLI logged some sort of ":mvn/repos is not supported inside of aliases" warning on launch.

Calva project type: shadow-cljs vs deps.edn + shadow-cljs?

Sat, 21 May 2022 19:46:14 +0000

Hi everyone, I’ve gone through the shadow-cljs quickstart guide in the GitHub repo README and got the desired message in the browser console. Next, I wanted to introduce deps.edn to the project. I had some (self-inflicted) difficulty in jacking in after adding deps.edn.

System details:
OS: WSL2
Java version: OpenJDK 11.0.15
Clojure CLI version: 1.11.1.1113

With only shadow-cljs.edn in the project, said file contents are:

;; shadow-cljs.edn
{:source-paths ["src/dev"
                "src/main"
                "src/test"]
 :dependencies []
 
 :dev-http {8080 "public"}
 :builds {:frontend {:target :browser
                     :modules {:main {:init-fn acme.frontend.app/init}}}}}

At this point, jacking in with Calva using the “shadow-cljs” project type, which both starts and connects to the “:frontend” build, works like a charm.

As mentioned in the first paragraph, I had difficulty with introducing deps.edn to the project.

Add deps.edn to the main project directory with the following contents:

;; deps.edn
{:paths ["src/main"
"src/dev"
"src/test"]

 :aliases
 {:cljs {:extra-deps {thheller/shadow-cljs {:mvn/version "2.19.0"}}}}}

Change shadow-cljs.edn to:

 ;; shadow-cljs.edn
    
 {:deps {:aliases [:cljs]}
        
:dev-http {8080 "public"}
        
:builds {:frontend {:target :browser
:modules {:main {:init-fn acme.frontend.app/init}}}}}

Jacking in with Calva using the “deps.edn + shadow-cljs” project type at this point leads to an error containing “Failed starting cljs repl for build: :frontend. Is the build running and connected?”

The Calva Connection Log also provides information, including: “shadow-cljs has not been started yet!” and “If you have a shadow-cljs server or watch running then you are not connected to that process.”

The build doesn’t seem to have been started. What if we run npx shadow-cljs watch frontend and then tried connecting to the REPL? Same error messages as before.

It turns out I should’ve instead kept using the “shadow-cljs” project type (in which case the addition of deps.edn goes down without a hitch).

This leads me to wonder:

When to use which project type?
Which is preferred for a fullstack
project?

Thanks to Peter and contributors for Calva!

Non informative error message if git/sha of dependency in deps.edn cannot be found

Tue, 22 Feb 2022 17:29:29 +0000

Having a deps.edn

{:deps {org.clojure/data.csv { :sha "e5beccad0bafdb8e78f19cba481d4ecef5fabf36"}}}

(which misses the git/url), I get only a not informative error message aboy a NPE

`
Error building classpath.
java.lang.NullPointerException

at clojure.string$starts_with_QMARK_.invokeStatic(string.clj:364)
at clojure.tools.gitlibs.impl$clean_url.invokeStatic(impl.clj:70)
at clojure.tools.gitlibs.impl$git_dir.invokeStatic(impl.clj:85)
at clojure.tools.gitlibs.impl$ensure_git_dir.invokeStatic(impl.clj:106)
at clojure.tools.gitlibs$procure.invokeStatic(gitlibs.clj:61)

This is specially a problem in cases of several coordinates in the deps.end, because it does not give a hint which coordinate has the issue.

This happens as well in scenarios of a wrong sha

How to developing multiple libraries/applications simultaneously?

Sat, 19 Feb 2022 12:26:48 +0000

This feels like a rather basic project setup issue. I just wanted to learn from the gurus and get some ideas for the best way to develop libraries in tandem

I write a lot of little programs and scripts in Clojure and those naturally have lots of little helper functions. As you write your main script/application you end up tweaking the helpers, covering new corner cases you expose etc. But these helper functions end up being copied around haphazardly between scripts and apps. Things like functions that convert formats or make plots etc. Obviously this isn't ideal!

I'd like to split these independent helper functions off into their own mini libraries

One workflow that I've seen is the "monorepo" setup. This is the design used by thing/geom. However I think long term this has proven to be a bit problematic b/c Karsten Schmidt ended up having a whole ton of awesome features.. but they're all wrapped up and hidden away in the mono repo. He has a whole matrix library there, and renderers and things for working with 3D geometry etc. etc. But I'm guessing there is a discoverability issue and maybe people don't wanna have to pull in the whole kitchen sink to access one tool in some corner

Instead I'm trying to find a nice deps.edn way of doing this but I don't really get what the language designers' expected workflow is.

There is a way to work with local repos: https://clojure.org/guides/deps_and_cli#_using_local_libraries
And then there is a way to work with remote repos: https://clojure.org/guides/deps_and_cli#_using_git_libraries (or you can work with Maven repos)

But how do you do both at once..? I obviously need to tweak and add features to the libraries as I work on the application :) Should I have a local development deps.edn that points at local folders and then another deps.edn with remote repos to distribute? (If so, what's the best way to set that up with Cider?)

Or can I have one deps.edn that looks locally and then falls back to remote repos if it doesn't find anything?

Or maybe there is a better alternative I haven't considered?

Just wondering how people are handling this

(Also posted here: https://clojureverse.org/t/how-to-developing-multiple-libraries-applications-simultaneously/8660)

Will tools.build be released as a jar?

Wed, 05 Jan 2022 15:02:43 +0000

I am developing a library with a dependency on tools.build and I would like to publish it as a jar. Whilst tools.build is only available as a git dep, I cannot include it as a dependency in my pom file. A wider discussion on this topic was held on this slack thread, where @alexmiller requested that I raise this topic here.

tools.deps.graph uses an outdated version of tools.deps.alpha that doesn't support :git/sha coordinates

Fri, 10 Dec 2021 12:54:46 +0000

Repro deps.edn:

{:deps {io.github.clojure/spec-alpha2 {:git/sha "99456b1856a6fd934e2c30b17920bd790dd81775"}}}

Running clj -X:project/graph-deps, where project/graph-deps is the following alias in ~/.clojure/deps.edn:

:project/graph-deps
{:replace-paths []
 :replace-deps  {org.clojure/tools.deps.graph {:mvn/version "1.0.63"}}
 :ns-default    clojure.tools.deps.graph
 :exec-fn       graph
 :exec-args     {:output "project-dependencies-graph.png"
                 :size   true}}

Results in:

Library io.github.clojure/spec-alpha2 has missing :sha in coordinate.

Bumping the version of tools.deps.alpha to 0.12.1090 seems to fix the issue

Allow absolute paths for file-based Git URLS

Fri, 05 Nov 2021 19:24:15 +0000

Type: Enhancement
Summary: Expand tools.gitlibs support for local Git URLs
Description:
When specifying a local file-based URL for a Git repo containing a dependency, I encounter the following error when using an absolute URL:

java.lang.IllegalArgumentException: /path/to/my/repo is not a relative path

    at clojure.java.io$as_relative_path.invokeStatic(io.clj:414)
    at clojure.java.io$file.invokeStatic(io.clj:426)
    at clojure.java.io$file.invoke(io.clj:418)
    at clojure.lang.ArraySeq.reduce(ArraySeq.java:111)
    at clojure.core$reduce.invokeStatic(core.clj:6829)
    at clojure.java.io$file.invokeStatic(io.clj:418)
    at clojure.tools.gitlibs.impl$git_dir.invokeStatic(impl.clj:59)
    at clojure.tools.gitlibs.impl$ensure_git_dir.invokeStatic(impl.clj:80)
    at clojure.tools.gitlibs$procure.invokeStatic(gitlibs.clj:61)
    at clojure.tools.deps.alpha.extensions.git$fn__1317.invokeStatic(git.clj:98)
    at clojure.tools.deps.alpha.extensions.git$fn__1317.invoke(git.clj:96)
    at clojure.lang.MultiFn.invoke(MultiFn.java:239)
    at clojure.tools.deps.alpha$expand_deps.invokeStatic(alpha.clj:425)
    at clojure.tools.deps.alpha$resolve_deps.invokeStatic(alpha.clj:495)
    at clojure.tools.deps.alpha$calc_basis.invokeStatic(alpha.clj:738)
    ...

The requirement of relative URLs makes specifying dependencies more difficult in certain contexts - the specific motivating use case for me is a WSL environment where the Clojure process is running in Ubuntu/WSL but the source code is in the Windows filesystem.

Alex Miller mentioned on the Clojurians Slack when I mentioned this problem that "that's really a subset of the problem - the code that translates git urls to cache dirs and libs doesn't handle either raw paths or relative urls."

Using a git SHA for a local git dependency?

Fri, 05 Nov 2021 19:12:28 +0000

Type: Enhancement

Summary: Use git SHAs + tags for local deps

Description:

Currently, when working with local dependencies, I cannot use a git tag to refer to a specific revision of a project. :local/root only respects the current version of the working tree, which can make using local deps under active development a bit trickier.

Support for SHAs and tags for local projects which are specified via file-based Git URLs would allow projects consuming local deps to specify the state of those projects unambiguously.

I previously asked a version of this question on the Clojurians slack and was referred here by Alex Miller.

Resolve git deps via artifactory

Wed, 15 Sep 2021 13:07:15 +0000

As a follow up to https://ask.clojure.org/index.php/8866/using-git-deps-in-a-restricted-environment?show=8866#q8866

Given the increasing usage of git deps (eg tools.build) it is increasingly painful to use in corporate environments without direct github access. The majority of such corporates use tools like artifactory which, other than proxy things like maven, also allow proxying GitHub.

Specifically it allows access, via an API, that will download a specific sha or tag from github as a zip/tar archive.

In a general sense, could tools.deps be augmented to support this use case? I can see a few scenarios:

Provide a remote/root or remote/archive that works similar to a local/root, but can source from an arbitrary zip/tar provided by a url
Similarly allow git deps to resolve from some archive provided from a url

Since the url will have the tag/sha in it, presumably tools.deps would not need to download it again unless the URL was changed.

How do I effectively use EDN with C/C++?

Tue, 07 Sep 2021 01:55:21 +0000

Hello, I'm very new to Clojure related technologies and I may be asking the wrong question.

I am looking into making a IPFS like proof of concept using EDN which can be integrated with classical system languages (namely the old duo of C/C++). I would like to create an interface for C++ that takes a template data structure from compile time and from a filename create and populate a data structure matching that template. In C, it would be some ugly thing with structs composed of an enum to indicate the current primitive (either a list, set, or bytes), a void pointer, and all that C hackiness. Then from these, similarly have serializes.

The reason for EDN in particular is that it appears to be a technically superior specification based on it's foundations. The lack of need for a top level containing data structure, and extensible types look like a very good foundation for any work. It looks like EDN is missing the same level of support as formats like JSON. That makes this tough, but I think I can justify contributing something here. I am looking for a solution that can be reused at some point as a part of a Linux kernel module for embedding this functionality as a file system, but that's a ways off.

How do I start on this kind of project? What details am I missing?

Hope tools.deps.alpha add feature for listing available aliases

Fri, 03 Sep 2021 07:54:40 +0000

I think add an option for listing out available aliases will be helpful when there are many alaises.

Here is my try. https://github.com/seancorfield/dot-clojure/issues/7

Support preparing :deps/:extra-deps in aliases

Sat, 07 Aug 2021 00:02:41 +0000

Right now there's no way to prepare dependencies only included as as :deps or :extra-deps in aliases with clj -X:deps prep. Adding support for an :aliases option that would prepare these be extremely helpful, e.g.

clj -X:deps prep :aliases '[:my-alias]'

Real-world use case: at Metabase we have a :drivers alias that adds several :local/root data warehouse driver subprojects to our classpath. For our Spark SQL driver we need to AOT a few :gen-class namespaces that we use as proxy JDBC drivers. Currently we have people run clj -X:deps prep in multiple directories; a way to pass aliases to prep would let us do this in a single command.

JIRA Issue: https://clojure.atlassian.net/browse/CLJ-2652

Add support for BOM (Bill Of Materials) dependencies

Mon, 02 Aug 2021 17:08:00 +0000

Currently, if you have a dependency that is a BOM on Maven, you have to track down what all the components of that BOM are and list them as explicit, individual dependencies. It would save a lot of detective work and redundancy if t.d.a supported this type of dependency directly.

git-resolve-tags doesn't support new format of git coords

Fri, 16 Jul 2021 13:30:54 +0000

With tools.deps v0.12.985+, the :git/url key is optional for git coords and the :sha and :tag keys are renamed to :git/sha and :git/tag, respectively. But clj -X:deps git-resolve-tags doesn't seem to support this new format of git coords yet.
This can be confirmed as follows:

$ cat deps.edn
{:deps {org.clojure/clojure {:mvn/version "1.10.3"}}
 :aliases
 {:build
  {:override-deps
   {io.github.clojure/tools.build {:git/tag "v0.1.3"}}}}}
$ clj -X:deps git-resolve-tags
Resolving git tags in deps.edn ...
No unresolved tags found.
$

Whereas:

$ cat deps.edn
{:deps {org.clojure/clojure {:mvn/version "1.10.3"}}
 :aliases
 {:build
  {:override-deps
   {io.github.clojure/tools.build
    {:git/url "https://github.com/clojure/tools.build.git"
     :tag "v0.1.3"}}}}}
$

can be resolved successfully:

$ clj -X:deps git-resolve-tags
Resolving git tags in deps.edn ...
Resolved v0.1.3 => 688245ea6cc8b3b173b79b861938444fcd9e3e1e in https://github.com/clojure/tools.build.git
$

Probably, the following lines should be updated accordingly:

:deps manifest dependencies do not respect :mvn/repos in dependent project

Thu, 24 Jun 2021 09:18:22 +0000

Problem

It's impossible to depend on a deps.edn-based project using git or local dependency when that project uses custom maven repos. Attempts to build classpath for projects depending on such projects will fail.

Repro

I created a minimal repo that illustrates the issue: https://github.com/vlaaad/deps-mvn-repos-repro

It contains 3 deps.edn projects: lib, app-local and app-git.

lib contains a single deps.edn file that defines a custom maven repo and a dependency that pulls from that repo.

app-local contains a single deps.edn file that defines a :local/root dependency on lib.

app-git contains a single deps.edn file that defines a :git/url dependency on lib.

Expected behavior

Running clj -P should succeed in lib, app-local and app-git projects.

Actual behavior

Running clj -P succeeds only in lib and fails in app-local and app-git with the error "Error building classpath. Could not find artifact net.sf.saxon:saxon-dom:jar:9.1.0.8 in central (https://repo1.maven.org/maven2/)"

Could tools.deps.alpha support :jvm-opts via aliases-as-data, the same as :paths/:extra-paths?

Mon, 07 Jun 2021 18:37:03 +0000

At work, we have four or five JVM options that are common to almost every invocation of the CLI via aliases in our deps.edn file. Currently, we have :jvm-opts duplicated into each alias.

It would reduce duplication if we could just say :jvm-opts :common-opts in each alias and have a :common-opts alias that specified the JVM options in just one place or, even better, if the :jvm-opts vector could take a mix of keywords and strings and look up the keywords as aliases and merge that data in.

This would make :jvm-opts consistent with :paths and :extra-paths and help reduce duplication in deps.edn files.

In our specific case, we could then do the following:

;; under :aliases
:common-jvm-opts ["-Dclojure.core.async.go-checking=true"
                  "-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory"
                  "-XX:-OmitStackTraceInFastThrow"
                  "--illegal-access=warn"]}

;; in a specific alias
:some-alias {
  :jvm-opts [:common-jvm-opts "-Dlogged-future=synchronous"]
}

Issue loading cognitect test-runner dependency in deps.edn: USERAUTH fail.

Wed, 24 Feb 2021 10:15:47 +0000

I am trying to use the Cognitect test-runner dependency to run my tests and I am getting a jgit USERAUTH fail when it tries to clone the dependency. I can use other test runners but I really want to know what is going on here. Lots of other people have had this issue, but I haven't found a good explanation of the issue, nor a resolution. Would appreciate both if anyone can help!

I'm using:

Java 8 (tried 11 too)
Mac 10.15.7 (Catalina)

I have a git ssh key without passcode

Can someone explain to me what the issue is? I have an idea that it's to do with jgit/jsch but I don't fully understand what the problem is.

my deps.edn :

  {:paths ["src" "resources"]
        :deps {org.clojure/clojure {:mvn/version "1.10.2"}}
        :aliases
         { :test {:extra-paths ["test"]
            :extra-deps {com.cognitect/test-runner
                               {:git/url "https://github.com/cognitect-labs/test-runner.git"
                                :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}}
            :main-opts ["-m" "cognitect.test-runner"]}}

clj -A:test output:

> Cloning: https://github.com/cognitect-labs/test-runner.git Error

> building classpath. git@github.com:cognitect-labs/test-runner.git:
> USERAUTH fail org.eclipse.jgit.api.errors.TransportException:
> git@github.com:cognitect-labs/test-runner.git: USERAUTH fail
>         at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:248)
>         at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:306)
>         at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:200)
>         at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:89)
>         at clojure.tools.gitlibs.impl$call_with_auth.invokeStatic(impl.clj:52)
>         at clojure.tools.gitlibs.impl$call_with_auth.invoke(impl.clj:43)
>         at clojure.tools.gitlibs.impl$git_clone_bare.invokeStatic(impl.clj:73)
>         at clojure.tools.gitlibs.impl$git_clone_bare.invoke(impl.clj:70)
>         at clojure.tools.gitlibs.impl$ensure_git_dir.invokeStatic(impl.clj:112)
>         at clojure.tools.gitlibs.impl$ensure_git_dir.invoke(impl.clj:102)
>         at clojure.tools.gitlibs$resolve.invokeStatic(gitlibs.clj:33)
>         at clojure.tools.gitlibs$resolve.invoke(gitlibs.clj:29)
>         at clojure.tools.gitlibs$procure.invokeStatic(gitlibs.clj:47)
>         at clojure.tools.gitlibs$procure.invoke(gitlibs.clj:41)
>         at clojure.tools.deps.alpha.extensions.git$eval1316$fn__1318.invoke(git.clj:42)
>         at clojure.lang.MultiFn.invoke(MultiFn.java:239)
>         at clojure.tools.deps.alpha$expand_deps.invokeStatic(alpha.clj:422)
>         at clojure.tools.deps.alpha$expand_deps.invoke(alpha.clj:390)
>         at clojure.tools.deps.alpha$resolve_deps.invokeStatic(alpha.clj:495)
>         at clojure.tools.deps.alpha$resolve_deps.invoke(alpha.clj:475)
>         at clojure.tools.deps.alpha$calc_basis.invokeStatic(alpha.clj:648)
>         at clojure.tools.deps.alpha$calc_basis.invoke(alpha.clj:622)
>         at clojure.tools.deps.alpha.script.make_classpath2$run_core.invokeStatic(make_classpath2.clj:91)
>         at clojure.tools.deps.alpha.script.make_classpath2$run_core.invoke(make_classpath2.clj:57)
>         at clojure.tools.deps.alpha.script.make_classpath2$run.invokeStatic(make_classpath2.clj:119)
>         at clojure.tools.deps.alpha.script.make_classpath2$run.invoke(make_classpath2.clj:113)
>         at clojure.tools.deps.alpha.script.make_classpath2$_main.invokeStatic(make_classpath2.clj:169)
>         at clojure.tools.deps.alpha.script.make_classpath2$_main.doInvoke(make_classpath2.clj:140)
>         at clojure.lang.RestFn.applyTo(RestFn.java:137)
>         at clojure.lang.Var.applyTo(Var.java:705)
>         at clojure.core$apply.invokeStatic(core.clj:667)
>         at clojure.main$main_opt.invokeStatic(main.clj:514)
>         at clojure.main$main_opt.invoke(main.clj:510)
>         at clojure.main$main.invokeStatic(main.clj:664)
>         at clojure.main$main.doInvoke(main.clj:616)
>         at clojure.lang.RestFn.applyTo(RestFn.java:137)
>         at clojure.lang.Var.applyTo(Var.java:705)
>         at clojure.main.main(main.java:40) Caused by: org.eclipse.jgit.errors.TransportException:
> git@github.com:cognitect-labs/test-runner.git: USERAUTH fail
>         at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:172)
>         at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:140)
>         at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:280)
>         at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:170)
>         at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:137)
>         at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:123)
>         at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1269)
>         at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:237)
>         ... 37 more Caused by: com.jcraft.jsch.JSchException: USERAUTH fail
>         at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:119)
>         at com.jcraft.jsch.Session.connect(Session.java:470)
>         at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:126)

Add the CLI equivalent of Leiningen's sample.project.clj

Tue, 26 Jan 2021 18:02:50 +0000

Leiningen has an option to display a fully-populated, well-documented project.clj file (as the sample.project.clj file from its installation.

The Clojure CLI has example-deps.edn which is laid down as ~/.clojure/deps.edn on first use. It does have some examples but it doesn't have all the possible options shown -- in particular it doesn't show where :jvm-opts should live (a lot of people seem to expect it to work as a top-level key in deps.edn despite what the reference docs say about it being part of an alias.

In addition, example-deps.edn still refers to -R and -C and doesn't mention -X or -M.

It also, somewhat confusingly, repeats several aliases from the system deps.edn file as comments, suggesting that those are useful things to uncomment in a user deps.edn file.

Could :replace-deps imply :replace-paths [] by default?

Tue, 15 Dec 2020 13:06:32 +0000

If an alias, or tool invocation using -Sdeps, discards a project's deps by using :replace-deps then there is a good chance that some or all of the project's namespaces become impossible to load due to their requirements now missing from the classpath.

If there are files in the project's default paths that are auto-loaded by clojure on startup, such as user.clj, the tool invocation might fail therefore. This can be mitigated by also specifying :replace-paths [], however this does not seem to be too well known (example 1, example 2, example 3).

I was wondering whether it is common for tools to replace a project's deps with their own but still use the project's paths? I believe in most cases the tool will be authored with no knowledge of the project it will be used in and should not expect to find anything useful to load from the project's own paths.

In order to make it easier to set up tool invocations, it would make sense to me to make :replace-deps imply :replace-paths [] unless otherwise specified, or something along these lines.

A repro case can be found at https://github.com/imrekoszo/depslink3_2#missing-replace-paths-repro-case

Migrated from https://ask.clojure.org/index.php/9857/could-option-that-variant-sdeps-avoid-having-specify-alias?show=9884#a9884

Edit: update opening paragraph to reference replace-deps as opposed to replace paths. I don't know why I wrote replace-paths there in the first place, this is about problems with replace-deps :)

Update: not happening, according to Alex: https://ask.clojure.org/index.php/11522/x-deps-might-fail-when-user-clj-requires-something?show=11526#c11526

How can teams share common dependencies/tooling across multiple projects with deps.edn?

Mon, 23 Nov 2020 20:34:46 +0000

Here's my general problem statement (this applies to a monorepo as well):

a development team works together on multiple projects that each have their deps.edn file, and
those developers have their own preferred tooling configured in their own ~/.clojure/deps.edn file, and
the team as a whole wants a level of consistency in terms of certain library or tooling versions across multiple projects, by providing some standardized aliases and some "pinned" versions (e.g., :override-deps or :default-deps).

Bullets 1. and 2. are supported by the CLI/t.d.a. but there's nowhere to hang the multi-project standardization piece.

Currently, folks who want 3. are using CLJ_CONFIG to provide a team-standard deps.edn file but losing 1. in the process. This is considered a bit of a hack (although CLJ_CONFIG is documented).

Michiel Borkent notes that his clj-kondo tool faced a similar problem in terms of where it reads configuration data from and his solution was to provide a command-line argument that specified multiple configuration files to read. A similar approach could be taken with the Clojure CLI, allowing an arbitrary number of deps.edn files to be combined (after the system + user level ones and before the command-line -Sdeps data).

The current "system + user + project + command-line" logic is baked into tools.deps.alpha itself so this is not just a CLI script change -- and whatever approach is taken to address this needs to be available to tooling that needs to run analysis based on a combined deps.edn environment under user-specific aliases (as discussed here https://ask.clojure.org/index.php/9848/tooling-based-tools-alpha-construct-basis-specified-aliases).

How do I resolve Maven dependencies for a local jar?

Mon, 23 Nov 2020 16:26:56 +0000

I'm having trouble resolving dependencies from a local .jar file. In short: they resolve when I run the .jar using java -jar, but they do not when pointing to the .jar in my deps.edn file.

The details:

I can successfully build and run the Java code in the Quickstart for plaid-java repository. This is my command:

java -jar target/quickstart-1.0-SNAPSHOT.jar server config.yml

However, when I include the jar in my deps.edn and run clj -Spath, I get this error for each of the .jar's dependencies:

[ERROR] Failed to determine Java version for profile...

This is the line that fails in my deps.edn file:

com.plaid/quickstart {:local/root "src/usermanager/java/target/quickstart-1.0-SNAPSHOT.jar"}

It may be worth noting that this project uses Dropwizard. Each dependency in the repository's pom.xml is listed as: <groupId>io.dropwizard</groupId>, <artifactId>dropwizard-bom</artifactId>, <version>${dropwizard.version}</version>. The version of Dropwizard resolves as 1.3.2.

I've tried two additional troubleshooting strategies:

mvn clean package rebuilds with no problem.
I've set my JAVA_HOME env var with no luck.

Thanks in advance!

clj -M: ignores :extra-paths in alias

Wed, 18 Nov 2020 00:49:01 +0000

Hi,

it seems there is a bug with using clj -M:foo with :extra-paths in :aliases the classpath seems to not include the extra-paths

deps.edn

{:aliases
 {:foo
  {:extra-paths ["dev"]
   :main-opts ["-m" "foo"]}}}

dev/foo.clj

(ns foo)

(defn -main
  [& args]
  (println "hello world"))

When running

clj -M:foo

We get

Execution error (FileNotFoundException) at clojure.main/main
(main.java:40). Could not locate foo__init.class, foo.clj or foo.cljc
on classpath.

Full report at: /tmp/clojure-8075946726191297006.edn

Whereas

clj -A:foo -m foo

gives

hello world

this difference is also visible via -Spath

clj -Spath -M:foo

src:/home/mark/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/home/mark/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/home/mark/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar

clj -Spath -A:foo

dev:src:/home/mark/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/home/mark/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/home/mark/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar

Issue with broken packages if repository doesn't resolve properly

Wed, 11 Nov 2020 16:17:26 +0000

My project edn had a old maven link that no longer resolves, since maven switched to https only in 2020:

:mvn/repos {"central" {:url "http://central.maven.org/maven2/"}

When retrieving deps from a new computer, the packages were all failing with errors like:

Downloading: selmer/selmer/1.12.31/selmer-1.12.31.pom from central
Download corrupted: Checksum validation failed, expected <meta but is ad208edec82716369dab76b6cbca3475a4ae2033

This was because the downloaded "package" were instead HTML files due to AT&T dnsassist.

Since the checksum fails, I would expect the package downloaded to be deleted instead of kept as it is (broken html files). I had to delete the entire .m2, fix the repo link, and then redownload to fix.

Why is the clj mvn-pom task ignoring the -Srepro option?

Wed, 30 Sep 2020 00:47:30 +0000

I have a user-level deps.edn and a project-level deps.edn. I want to generate a pom.xml file for my project that ignores any dependencies in my user-level deps.edn. The command I have now is:

clj -Srepro -X:deps mvn-pom

According to the docs (and to the report provided by -Sverbose), this should ignore my user-level deps.edn. But I still see the dependencies from my user deps.edn appearing in the generated pom.xml! I've tried this with -Sforce also and nothing changed. Whether I use -Spom or -X:deps mvn-pom, it seems like the -Srepro option is ignored.

Here's more info about my environment:

$ clj -Srepro -Sverbose -Sdescribe
version      = 1.10.1.697
install_dir  = /usr/local/Cellar/clojure/1.10.1.697
config_dir   = /Users/jming/.clojure
config_paths = /usr/local/Cellar/clojure/1.10.1.697/deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache/1655984260.cp

{:version "1.10.1.697"
 :config-files ["/usr/local/Cellar/clojure/1.10.1.697/deps.edn" "deps.edn" ]
 :config-user ""
 :config-project "deps.edn"
 :install-dir "/usr/local/Cellar/clojure/1.10.1.697"
 :config-dir "/Users/jming/.clojure"
 :cache-dir ".cpcache"
 :force false
 :repro true
 :main-aliases ""
 :repl-aliases ""}

What am I doing wrong? Why does -Srepro appear to be doing nothing, despite what -Sverbose says? How can I keep user-level dev dependencies like cljfmt out of my pom.xml?

Proper deps.edn config with -co option of cljs.main

Thu, 09 Jul 2020 15:55:05 +0000

Hello,

I am trying translate the following cljs.main options with the CLI:

$ clj -m cljs.main          \
      -d public/js/compiled \
      -o public/js/main.js  \
      -O advanced           \
      -c hello-world.core

Into deps.edn:

{:deps {org.clojure/clojurescript {:mvn/version "1.10.764"}
        reagent {:mvn/version "1.0.0-alpha2"}}
 :main "hello-world.core"
 :optimizations :advanced
 :output-dir "public/js/compiled"
 :output-to "public/js/main.js"}

Then execute it with:

clj -m cljs.main -co deps.edn

However, it doesn't seem to work.

I also get the following error using the generated main.js file:

main.js:314 Uncaught TypeError: Cannot read property 'mg' of undefined
    at Mb (main.js:314)
    at Tn (main.js:699)
    at Rn (main.js:698)
    at Nn.h.Me (main.js:718)
    at Function.Wn.A (main.js:710)
    at Nn.h.Le (main.js:718)
    at Function.Wn.j (main.js:710)
    at ep (main.js:761)
    at main.js:761

Some thoughts

Am I missing a CLI option? or deps.edn key/value pair?
Am I using it wrong; the CLI or deps.edn or both?
Or is it not well supported at the moment so I should just stick with the CLI?

Allow (transitive) deps.edn dependencies to inherit aliases

Thu, 14 May 2020 07:43:39 +0000

When enabling aliases when starting clojure, would it make sense to propagate those aliases when processing the deps.edn files of (transitive) dependencies?

This is related to but different from: Allow specifying aliases in coordinates that point to deps.edn projects (JIRA TDEPS-116).

Use case:

I'm developing a number of interrelated libraries. One of them, lambdaisland/chui-ui, has a dev dependency on garden. The released version does not need garden, it contains the compiled css instead.

chui-ui is a dependency of chui, and chui is a dependency of kaocha-cljs2. While working on either of these I use :local/root to set up the dependencies, so that I can easily work across these different sources.

;; chui-ui {:aliases {:dev {:extra-deps {garden ...}}}}

;; chui {:deps {chui-ui {:local/root "modules/chui-ui"}}}

;; kaocha-cljs2 {:deps {chui {:local/root "../chui"}}}

But this doesn't work as such, because when I start clojure -A:dev inside chui or kaocha-cljs2, then the garden dependency is not picked up. To make this work I need to copy that :dev alias with garden to the top level project, even though chui or kaocha-cljs2 are not concerned with garden.

clj -m works from shell but not as alias

Wed, 15 Jan 2020 07:18:08 +0000

Running the following at the command line:

clj -Acider -m "nrepl.cmdline" "--middleware" "[refactor-nrepl.middleware/wrap-refactor cider.nrepl/cider-middleware]"

Given:

:cider {:extra-deps {nrepl {:mvn/version "0.6.0"}
                                refactor-nrepl {:mvn/version "2.5.0-SNAPSHOT"}
                                cider/cider-nrepl {:mvn/version "0.23.0-SNAPSHOT"}}}

Works. But moving it to a :main-opts:

:cider {:extra-deps {nrepl {:mvn/version "0.6.0"}
                                refactor-nrepl {:mvn/version "2.5.0-SNAPSHOT"}
                                cider/cider-nrepl {:mvn/version "0.23.0-SNAPSHOT"}}
                   :main-opts ["-m" "nrepl.cmdline" "--middleware" "[refactor-nrepl.middleware/wrap-refactor cider.nrepl/cider-middleware]"]}

And running:

clj -Acider

Fails with:

Exception in thread "main" java.lang.RuntimeException: EOF while reading                                                         [5/723]
        at clojure.lang.Util.runtimeException(Util.java:221)                                                                            
        at clojure.lang.EdnReader.readDelimitedList(EdnReader.java:746)                                                                 
        at clojure.lang.EdnReader$VectorReader.invoke(EdnReader.java:672)                                                               
        at clojure.lang.EdnReader.read(EdnReader.java:145)                                                                              
        at clojure.lang.EdnReader.read(EdnReader.java:111)                                                                              
        at clojure.lang.EdnReader.readString(EdnReader.java:67)
        at clojure.edn$read_string.invokeStatic(edn.clj:46)
        at clojure.edn$read_string.invokeStatic(edn.clj:37)
        at clojure.edn$read_string.invoke(edn.clj:37)
        at nrepl.cmdline$parse_cli_values$fn__1275.invoke(cmdline.clj:248)
        at clojure.core$fn__8072$fn__8074.invoke(core.clj:6760)
        at clojure.core.protocols$iter_reduce.invokeStatic(protocols.clj:49)
        at clojure.core.protocols$fn__7839.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7839.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$fn__8072.invokeStatic(core.clj:6750)
        at clojure.core$fn__8072.invoke(core.clj:6750)
        at clojure.core.protocols$fn__7860$G__7855__7869.invoke(protocols.clj:175)
        at clojure.core$reduce_kv.invokeStatic(core.clj:6776)
        at clojure.core$reduce_kv.invoke(core.clj:6767)
        at nrepl.cmdline$parse_cli_values.invokeStatic(cmdline.clj:246)
        at nrepl.cmdline$parse_cli_values.invoke(cmdline.clj:242)
        at nrepl.cmdline$args__GT_cli_options.invokeStatic(cmdline.clj:261)
        at nrepl.cmdline$args__GT_cli_options.invoke(cmdline.clj:253)
        at nrepl.cmdline$_main.invokeStatic(cmdline.clj:447)
        at nrepl.cmdline$_main.doInvoke(cmdline.clj:443)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:702)
        at clojure.core$apply.invokeStatic(core.clj:657)
        at clojure.main$main_opt.invokeStatic(main.clj:317)
        at clojure.main$main_opt.invoke(main.clj:313)
        at clojure.main$main.invokeStatic(main.clj:424)
        at clojure.main$main.doInvoke(main.clj:387)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:702)
        at clojure.main.main(main.java:37)

`clj` and `deps.edn` do not support newer ssh private key file formats and key types such as ed25519

Sun, 13 Oct 2019 11:37:33 +0000

clj and tools.gitlibs use an old jsch via jgit library. jsch doesn't support all the private
keys formats and key types created by OpenSSH ssh-keygen. This can cause rather cryptic error messages
(see below of a stacktrace). JGit has added support for these in a recent version by switching jsch to another ssh implementation.

https://wiki.eclipse.org/JGit/New_and_Noteworthy/5.2

Currently tools.gitlibs uses org.eclipse.jgit:org.eclipse.jgit 4.10.0.201712302008-r
when current version for jgit is 5.5.1.201910021850-r.

There have been a bunch of issues related to jsch before https://clojure.atlassian.net/browse/TDEPS-91.

Seems that private keys starting with this line are not supported. And this is what openssh
ssh-keygen creates by default:

-----BEGIN OPENSSH PRIVATE KEY-----

For example this kind of errors happen when using unsupported ssh private key format:
`
Cloning: https://github.com/cognitect-labs/test-runner
Error building classpath. git@github.com:cognitect-labs/test-runner: invalid privatekey: [B@71d55b7e
org.eclipse.jgit.api.errors.TransportException: git@github.com:cognitect-labs/test-runner: invalid privatekey: [B@71d55b7e

at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:248)
at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:306)
at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:200)
at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:89)
at clojure.tools.gitlibs.impl$call_with_auth.invokeStatic(impl.clj:50)
at clojure.tools.gitlibs.impl$call_with_auth.invoke(impl.clj:41)
at clojure.tools.gitlibs.impl$git_clone_bare.invokeStatic(impl.clj:71)
at clojure.tools.gitlibs.impl$git_clone_bare.invoke(impl.clj:68)
at clojure.tools.gitlibs.impl$ensure_git_dir.invokeStatic(impl.clj:110)
at clojure.tools.gitlibs.impl$ensure_git_dir.invoke(impl.clj:100)
at clojure.tools.gitlibs$resolve.invokeStatic(gitlibs.clj:33)
at clojure.tools.gitlibs$resolve.invoke(gitlibs.clj:29)
at clojure.tools.gitlibs$procure.invokeStatic(gitlibs.clj:47)
at clojure.tools.gitlibs$procure.invoke(gitlibs.clj:41)
at clojure.tools.deps.alpha.extensions.git$eval966$fn__968.invoke(git.clj:41)
at clojure.lang.MultiFn.invoke(MultiFn.java:239)
at clojure.tools.deps.alpha$expand_deps.invokeStatic(alpha.clj:181)
at clojure.tools.deps.alpha$expand_deps.invoke(alpha.clj:164)
at clojure.tools.deps.alpha$resolve_deps.invokeStatic(alpha.clj:231)
at clojure.tools.deps.alpha$resolve_deps.invoke(alpha.clj:213)
at clojure.tools.deps.alpha.script.make_classpath$create_classpath.invokeStatic(make_classpath.clj:61)
at clojure.tools.deps.alpha.script.make_classpath$create_classpath.invoke(make_classpath.clj:53)
at clojure.tools.deps.alpha.script.make_classpath$run.invokeStatic(make_classpath.clj:79)
at clojure.tools.deps.alpha.script.make_classpath$run.invoke(make_classpath.clj:72)
at clojure.tools.deps.alpha.script.make_classpath$_main.invokeStatic(make_classpath.clj:118)
at clojure.tools.deps.alpha.script.make_classpath$_main.doInvoke(make_classpath.clj:93)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.main$main_opt.invokeStatic(main.clj:514)
at clojure.main$main_opt.invoke(main.clj:510)
at clojure.main$main.invokeStatic(main.clj:664)
at clojure.main$main.doInvoke(main.clj:616)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.main.main(main.java:40)

Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:cognitect-labs/test-runner: invalid privatekey: [B@71d55b7e

at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:172)
at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:140)
at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:280)
at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:170)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:137)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:123)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1269)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:237)
... 35 more

Caused by: com.jcraft.jsch.JSchException: invalid privatekey: [B@71d55b7e

at com.jcraft.jsch.KeyPair.load(KeyPair.java:948)
at com.jcraft.jsch.KeyPair.load(KeyPair.java:561)
at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40)
at com.jcraft.jsch.JSch.addIdentity(JSch.java:407)
at com.jcraft.jsch.JSch.addIdentity(JSch.java:367)
at org.eclipse.jgit.transport.JschConfigSessionFactory.getJSch(JschConfigSessionFactory.java:320)
at org.eclipse.jgit.transport.JschConfigSessionFactory.createSession(JschConfigSessionFactory.java:257)
at org.eclipse.jgit.transport.JschConfigSessionFactory.createSession(JschConfigSessionFactory.java:188)
at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:119)
... 42 more

How do you use a private maven repository with deps.edn

Mon, 09 Sep 2019 13:04:05 +0000

So I'm trying to play around with deps.edn at work, but we have artifacts in a private maven repo, in leinigen we just specify the maven repo like so

`:repositories [["my.datomic.com" {:url "https://my.datomic.com/repo"

                                :username [:gpg :env/mydatomic_username]
                                :password [:gpg :env/mydatomic_password]}]
             ["releases" {:url           "https://nexus.example.com/content/repositories/releases"
                          :sign-releases false
                          :username      [:gpg :env/nexus_write_username]
                          :password      [:gpg :env/nexus_write_password]}]
             ["snapshots" {:url      "https://nexus.example.com/content/repositories/snapshots"
                           :username [:gpg :env/nexus_write_username]
                           :password [:gpg :env/nexus_write_password]}]]`

I know that I can specify maven repos in deps.edn with :mvn/repos, but I don't see a way to get the username and password from the environment

Failure on github import via deps

Tue, 03 Sep 2019 17:51:12 +0000

I'm trying to resurrect an old monzo API wrapper for use in a project, so far I've forked the old repo to https://github.com/slifin/monzo-clj and now I would like to use my forked version in a Datomic cloud project

I've added the following keys to my deps.edn (stripped for clarity):

:deps {
    slifin/monzo-clj {:git/url "https://github.com/slifin/monzo-clj" :sha "54d925c23f62e914fa9e6fa5eb22c3e7040eb304"}}
 }

but everytime I run clj on the terminal I get this error

Error building classpath. Manifest type not detected when finding deps for slifin/monzo-clj in coordinate {:git/url "https://github.com/slifin/monzo-clj", :sha "54d925c23f62e914fa9e6fa5eb22c3e7040eb304"}

What am I doing wrong?

Equivalent of Leiningen's :managed-dependencies in deps.edn?

Thu, 22 Aug 2019 21:42:05 +0000

Leiningen has a feature called Managed Dependencies. This lets you set a common version for a transitive dependency to be used instead of relying on versions provided by your dependencies. This is useful when you want to specify a version of a library without actually adding a dependency on it. It has a very similar effect (I think) as adding the dependency directly to your Leiningen :dependencies, but communicates the intention better.

Is there something similar like this in deps.edn? A way to specify a version resolution for a dependency without adding it directly to :deps?