Fork me on GitHub

I’m trying to use a private bitbucket repo as a git dep but getting “auth fail” from the jgit layer. I’ve tested ssh access from the terminal and that’s working. anyone else had any luck with this?


I think that is only partially supported at he moment...?


(I'm trying to find the public discussions about it)


Hmm, OK, looks like ssh keypair should work for git deps...


In particular "Note: user/password authentication is not supported for any protocol."


How do you have your repo configured in deps.edn @steveb8n?


thx for quick response. I’m using an SSH key with ssh-agent on OSX i.e. not using un/pw


in deps.edn I follow the pattern I’m using for some public repos i.e. same keys


only difference is :git/url is ssh: instead of https:


when I run ssh -v in CLI, that shows successful connection


hmm, it looks like I am missing a “registered identity”


I’ll dig deeper into that


and will report back


I found the problem. I am using the OSX ssh-agent with the OSX keychain and it’s not persistent between reboots


ssh-add -K fixed it


thanks for pointing me in the right direction


Cool! The whole ssh keys/identity thing can be a bear...


yep. in this case it’s a different behaviour in zsh CLI vs jgit (part of tools.deps). I’ve written it down in my readme for next time 🙂


@seancorfield a heads up for future. when using git private deps in CI, you must invoke the ssh-agent before invoking clojure i.e. eval ssh-agent -s``


those double backticks should be single (I’m no good at slack code


this should probably go in some docs somewhere

Christian Johansen08:10:31

Whenever I have compilation errors in my code, starting a REPL with clojure -A:dev only gives me this:

Christian Johansen08:10:34

clj -A:dev
2018-10-25 10:06:47.433:INFO::main: Logging initialized @10380ms
Exception in thread "main" java.lang.ExceptionInInitializerError
	at clojure.main.<clinit>(

Christian Johansen08:10:39

can this be improved somehow?

Christian Johansen08:10:56

a stack trace, anything to point me towards the problem?


@christian767 my immediate thought is to try Clojure 1.10 alphas. As there's been some big changes around this stuff.

Christian Johansen08:10:41

this is with 1.10.0-alpha8

Christian Johansen08:10:58

I’ll try an even newer one

Christian Johansen08:10:57

with clojure-tools- and Clojure 1.10.0-beta4:

Christian Johansen08:10:00

clj -A:dev
2018-10-25 10:30:49.453:INFO::main: Logging initialized @11217ms
Exception in thread "main" java.lang.ExceptionInInitializerError
	at clojure.main.<clinit>(


So that's failing before it even gets Clojure up and running...


You'll need to share some of your deps.edn (possibly both your ~/.clojure version and your project one).


Does it start a REPL without -A:dev?


If so, your :dev alias is the problem.


OK, so what's in your :dev alias?

Christian Johansen08:10:17

I have dev/user.clj, and in it I’m still using a dependency I ditched yesterday

Christian Johansen08:10:26

[yonatane.timbre-json :as timbre-json]

Christian Johansen08:10:07

is there something I could’ve done to have this reported in an understandable way?

Christian Johansen08:10:42

(there was an :extra-paths in :dev)


Maybe wrap the contents of your user.clj file in (try ... (catch Throwable t (println "dev/user.clj broke" t)))

Christian Johansen08:10:23

can you try around the ns form?

Christian Johansen08:10:36

anyway, what if the error was in my source? can’t try-catch all my code


Sure. ns is just code.

👀 4
Christian Johansen08:10:06

seems strange to have to try-catch all my code to see compilation failures


Well, true, if your user.clj won't actually compile that's just going to break. user.clj is pretty special so you really should be very sparing about what you do in it.


You could always debug it with clj dev/user.clj I think?


(without the -A:dev alias, it wouldn't be on your classpath so it wouldn't automatically run at Clojure startup)

Christian Johansen08:10:48

my impression was that I always got this behavior with any compilation errors, but you’re saying this is happening because it’s in user?


Right, because it's executed as part of starting Clojure.

Christian Johansen08:10:41

by extension, this would happen with anything required from user too then?


Well, wrapping the ns form in try/`catch` should deal with that.

Christian Johansen08:10:39

leiningen manages to report this more clearly, I wonder why that is


Because Leiningen starts two JVMs perhaps?


OK, it's crazy late hear. I'm off to bed (nearly 2am).

Christian Johansen08:10:54

whoa, It’s 10 in the morning over here 🙂

Christian Johansen08:10:57

thanks for your help


Hopefully other folks will be coming online soon if you have other Qs.

Christian Johansen09:10:56

it’s quite the buzzkill for new tools.deps users

Christian Johansen10:10:50

not putting code in user.clj seems like the better approach for now. is there a tools.deps analog to leiningens :repl-options {:init-ns}?


In edge we solve this by having a dev.clj

Christian Johansen10:10:35

how do you load it?

Alex Miller (Clojure team)12:10:29

I suspect this is really a Clojure problem, not a tools.deps problem

Christian Johansen12:10:05

yes, after discussing with more people I realize it probably is

Christian Johansen12:10:21

sorry for misplacing the Jira issue…

Alex Miller (Clojure team)12:10:00

No worries, it can be moved


thanks for the depstar fix @seancorfield - it works like a charm!


I plan to actively maintain my fork, going forward, because we're relying heavily on it at work.


I've also started using it for packaging library JARs for deployment to Clojars now (there's an hf.depstar.jar entry point for thin JARs now, then clj -Spom -- and one-off updates to add/update license, SCM, etc -- and then mvn deploy:deploy-file).


Cool. I’ll probably be looking long and hard at depstar vs pack.alpha shortly just because I need to start generating manifests from Katamari, but if I stick with depstar I’d be happy to support your copy if its intent is to be active.


My experiment worked!


The experiment was: Git deps allow you to be a shitty maintainer because someone can just fork and change the url, without having to deploy an artifact


I learned this by making a simple PR to cognitect/test-runner that was ignored for months: but I had no problem because I forked it internally and pointed to our un-busted fork


I've been waiting for that PR to be merged. 😞


@seancorfield didn't have to do anything to unblock himself on depstar, which I neglected to maintain


:thinking_face: maybe {:mvn/version } could let you pass it an override lib to get the same place without refactoring your deps lists …


There's a ticket for this


:rolling_on_the_floor_laughing: @ghadi Although I have now deployed artifacts of seancorfield/depstar -- using the modified version of depstar! 🙂


if you break the API in a significant way I'll kindly ask you to rename


but I'm happy that you're happy sean!


It's a really good name if I do say so -- it's tar for deps, and a deathstar

💯 4

I like the simplicity of it. So far, I've only fixed bugs in the existing code and added a new namespace/entry point (for thin JARs). No API changes 🙂


when I use a :local/root dep, I’m finding that all my aliases are unavailable. workaround is to add copies of all aliases (with empty maps) into the dependencies deps.edn. Is this known?


@steveb8n AFAIK this is intended behavior - clj/`clojure` do not yet support merging “shared” extra deps files eg. for aliases besides the install global file and the user config.


I think seancorfield has done some hacking to be able to share a defaults file within a monorepo as have I.


hmm, in that case 1/ it would be good to doc this in the :local/root docs and 2/ does the workaround I discovered make sense?


I’m good to go with the workaround but just asking for others who will inevitably hit this


that’s my version of “asking for a friend”


It doesn't make sense for aliases in a deps project you depend on to bleed into your project's deps.


:local/root is nothing special -- just a want to specify a dependency. You wouldn't want all the aliases from a random :git/url deps file to bleed into your project, would you?


The aliases available to you should always be: system deps + user deps (which can be anywhere based on CLJ_CONFIG env var) + project deps.


I’ve been kicking around whether it makes sense to want to build deps with aliases - eg what if I wanted to let every one of my dependencies apply its :test alias so that I get a single classpath with all the machinery required to run all my deps’ tests.