This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-25
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # aws (2)
- # beginners (151)
- # boot (1)
- # calva (1)
- # cider (19)
- # clara (47)
- # cljdoc (9)
- # cljs-dev (25)
- # clojars (18)
- # clojure (151)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-dev (17)
- # clojure-italy (42)
- # clojure-nl (34)
- # clojure-spec (67)
- # clojure-uk (125)
- # clojurescript (163)
- # core-async (106)
- # cursive (19)
- # data-science (11)
- # datomic (9)
- # duct (2)
- # figwheel (1)
- # figwheel-main (6)
- # fulcro (97)
- # graphql (9)
- # instaparse (4)
- # jobs (6)
- # jobs-discuss (21)
- # leiningen (62)
- # mount (23)
- # off-topic (16)
- # re-frame (15)
- # reagent (16)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (9)
- # shadow-cljs (176)
- # tools-deps (102)
- # unrepl (3)
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
I found the problem. I am using the OSX ssh-agent with the OSX keychain and it’s not persistent between reboots
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``
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
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.
by extension, this would happen with anything require
d from user
too then?
Well, wrapping the ns
form in try
/`catch` should deal with that.
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).
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}
?
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.
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! 🙂
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
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.