Fork me on GitHub
#tools-deps
<
2018-10-25
>
steveb8n05:10:39

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?

seancorfield05:10:05

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

seancorfield05:10:19

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

seancorfield05:10:51

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

seancorfield05:10:45

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

seancorfield05:10:10

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

steveb8n05:10:13

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

steveb8n05:10:41

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

steveb8n05:10:59

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

steveb8n05:10:37

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

steveb8n05:10:08

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

steveb8n05:10:14

I’ll dig deeper into that

steveb8n05:10:45

and will report back

steveb8n05:10:02

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

steveb8n05:10:12

ssh-add -K fixed it

steveb8n05:10:24

thanks for pointing me in the right direction

seancorfield05:10:30

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

steveb8n05:10:33

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 🙂

steveb8n10:10:13

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

steveb8n10:10:22

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

steveb8n10:10:33

this should probably go in some docs somewhere

cjohansen08:10:31

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

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

cjohansen08:10:39

can this be improved somehow?

cjohansen08:10:56

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

dominicm08:10:42

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

cjohansen08:10:41

this is with 1.10.0-alpha8

cjohansen08:10:58

I’ll try an even newer one

cjohansen08:10:57

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

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

seancorfield08:10:05

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

seancorfield08:10:39

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

seancorfield08:10:05

Does it start a REPL without -A:dev?

seancorfield08:10:15

If so, your :dev alias is the problem.

seancorfield08:10:52

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

cjohansen08:10:58

found the culprit

cjohansen08:10:17

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

cjohansen08:10:26

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

cjohansen08:10:07

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

cjohansen08:10:42

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

seancorfield08:10:44

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

cjohansen08:10:23

can you try around the ns form?

cjohansen08:10:36

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

seancorfield08:10:43

Sure. ns is just code.

👀 4
cjohansen08:10:06

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

seancorfield08:10:33

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.

seancorfield08:10:52

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

seancorfield08:10:26

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

cjohansen08: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?

seancorfield08:10:10

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

cjohansen08:10:41

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

seancorfield08:10:07

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

cjohansen08:10:39

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

seancorfield08:10:58

Because Leiningen starts two JVMs perhaps?

seancorfield08:10:40

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

cjohansen08:10:54

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

cjohansen08:10:57

thanks for your help

seancorfield08:10:58

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

cjohansen09:10:56

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

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

dominicm10:10:21

In edge we solve this by having a dev.clj

cjohansen10: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

cjohansen12:10:05

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

cjohansen12:10:21

sorry for misplacing the Jira issue…

Alex Miller (Clojure team)12:10:00

No worries, it can be moved

arrdem19:10:53

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

seancorfield19:10:22

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

seancorfield19:10:56

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

arrdem20:10:46

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.

ghadi20:10:55

My experiment worked!

ghadi20:10:45

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

ghadi20:10:46

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

zane22:10:08

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

ghadi20:10:32

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

arrdem20:10:08

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

dominicm05:10:30

There's a ticket for this

seancorfield21:10:18

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

ghadi21:10:45

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

ghadi21:10:54

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

ghadi21:10:25

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

💯 4
seancorfield21:10:27

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 🙂

steveb8n22:10:17

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?

arrdem23:10:48

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

arrdem23:10:50

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

steveb8n23:10:07

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?

steveb8n23:10:39

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

steveb8n23:10:36

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

seancorfield23:10:30

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

seancorfield23:10:17

: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?

seancorfield23:10:18

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

arrdem23:10:49

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.