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...

See Procurers > Git Configuration here https://www.clojure.org/reference/deps_and_cli#_procurers

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 🙂

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

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>(main.java:20)

can this be improved somehow?

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.

this is with 1.10.0-alpha8

I’ll try an even newer one

with clojure-tools-1.9.0.397 and Clojure 1.10.0-beta4:

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>(main.java:20)

😢

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.

good tip

sure does

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

found the culprit

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

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

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

(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)))

can you try around the ns form?

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

Sure. ns is just code.

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?

interesting

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

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.

I see

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

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

right

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

Because Leiningen starts two JVMs perhaps?

aha

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

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

thanks for your help

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

👍

I reported this as an enhancement: https://dev.clojure.org/jira/browse/TDEPS-102

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

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 my-app.dev}?

In edge we solve this by having a dev.clj

how do you load it?

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

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

sorry for misplacing the Jira issue…

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: https://github.com/cognitect-labs/test-runner/pull/16 but I had no problem because I forked it internally and pointed to our un-busted fork

@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 …

: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

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.