This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-22
Channels
- # announcements (1)
- # beginners (109)
- # boot (2)
- # calva (26)
- # cider (6)
- # circleci (6)
- # cljsrn (3)
- # clojure (77)
- # clojure-dev (5)
- # clojure-europe (28)
- # clojure-finland (1)
- # clojure-hamburg (1)
- # clojure-italy (21)
- # clojure-japan (13)
- # clojure-nl (36)
- # clojure-spec (22)
- # clojure-sweden (4)
- # clojure-uk (105)
- # clojurescript (91)
- # community-development (8)
- # cursive (60)
- # datascript (3)
- # datomic (4)
- # emacs (33)
- # fulcro (19)
- # graalvm (38)
- # hoplon (4)
- # instaparse (1)
- # jobs (1)
- # leiningen (22)
- # off-topic (14)
- # pathom (2)
- # perun (4)
- # planck (5)
- # re-frame (10)
- # reagent (1)
- # reitit (11)
- # rum (11)
- # shadow-cljs (97)
- # tools-deps (82)
- # vim (53)
maybe bit late to realize, that using tools.deps to resolve deps with any other build-system, requires clojure tools to be installed. I bumped into this https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/reader.clj#L21 where I got an error on a windows machine. But I wonder, is this really necessary, can't every function from the clojure binary be called from another clojure code?
@hlolli That's the easiest (and only supported) way for tooling to get the list of system, user, and local deps.edn
files.
On Windows, you'll either need to use the alpha PowerShell installer for the Clojure tools, or stick with WSL and one of the "bash on Windows" Linux options.
I'd recommend not using tools.deps
with other build systems (as the author of boot-tools-deps
) and just go with clojure
/ clj
directly instead.
In a very early version of tools.deps
it did not shell out to clojure
. It was changed to do that to get around a lot of other problems people were having with tooling.
well, tools.deps is still alpha, so let's see what happens. I'd root for keeping it as a library, no matter how much sweat and blood is needed (none of it coming from me π ). Then it also enables calling it straight from java without any deps.
At this point, it's pretty fixed in stone that it's going to shell out to clojure
I think.
That's why there's been so much work done on getting a clojure
command working on Windows (via PowerShell).
I initially wrote boot-tools-deps
thinking that combining Boot with clj
/`deps.edn` was a good approach but once I started using it, I realized it really wasn't. Boot's ideas of paths and dependencies don't mesh well with the Clojure tools -- and it was just easier to stop using Boot altogether. I would imagine the same is really true of Leiningen as well.
yes, I'm starting to think that. Or I start writing tool dependent code if lein x elseif tools.deps y. Which I've never done with clojure.
These days I'm just targeting clj
/`deps.edn` but I'm also releasing libs to Clojars so they can be used by lein
/`boot`.
We switched our entire stack from Boot to clj
/`deps.edn` last year. We've been very happy with that.
yes I bet, it's just so unneeded I think, to tell everybody to change build tool, even tough tools.deps rocks and I would want everybody to use it
If folks are happy with lein
/`boot`, stay with lein
/`boot`. Don't try to blend them tho' π
yes, I agree with the fact that the my world would be a better place if everybody used tools.deps
-Sdescribe doesn't need to shell out if there isn't an install deps.edn, which may happen
ah that explains! the mix here of project.clj and deps.edn in a directory is probably confusing
@alexmiller Tooling that calls clojure-env
depends on tools.deps
shelling out -- to run clojure -Sdescribe
.
Are you saying that tooling could figure out it doesn't need to call clojure-env
?
@hlolli Which project are you looking at that has both project.clj
and deps.edn
? That usually means it's a Leiningen project that has added deps.edn
so folks can rely on that project on GitHub directly from their own deps.edn
...
(it doesn't mean the project is relying on Leiningen using tools.deps
)
well what are you calling clojure-env for?
I assume the locations of the deps.edn files
Right, so that those can be passed back in to tools.deps
...
there are 3 - install (goes away), ~/.clojure (deterministic based on env vars), current directory
the first one is the hard one
Ah, and you're going to fold the system/install one back into the library, right?
this also removes the biggest pain in the ass in the installer which is also finding that path
well, maybe it's the path to the jar itself
(which is what I had originally done with boot-tools-deps
-- baked in a copy of it from the Clojure tools repo π )
yeah. doesn't even need to be a file, could just hardcode parts of it
this project in question is Overtone, I wanted to add support for tools.deps, so I had to add badegion to extract the native deps. Badegion is what's calling tools.deps.alpha namespace. But in discssion with the maintainer of badegion, it seems I can do all that without deps.edn being in the jarfile.
the root deps.edn is just:
{
:paths ["src"]
:deps {
org.clojure/clojure {:mvn/version "1.10.0"}
}
:aliases {
:deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "0.6.496"}}}
:test {:extra-paths ["test"]}
}
:mvn/repos {
"central" {:url " "}
"clojars" {:url " "}
}
}
OK, once tools.deps
bakes that in and all the tooling has rev'd to depend on that version and everyone has updated to the latest versions of those tools, we will all be set! π
I am now remembering this discussion -- but it was quite a while ago and I guess I'd forgotten that it was seriously being considered. Good to hear @alexmiller
you can also just use tools.deps directly, hard-code your own deps.edn root with the stuff you need from that, and not ever call clojure-env
which is admittedly more work, but is also something that does not depend on anyone else doing anything
Yeah, but I think tooling has all evolved to assume that calling clojure-env
is the "correct, supported way" to get that information :rolling_on_the_floor_laughing:
lein-tools-deps
has actually copied in that function https://github.com/RickMoynihan/lein-tools-deps/blob/master/src/lein_tools_deps/env.clj#L32
@seancorfield amazing, thanks, my error is actually coming from right there but not tools.deps.alpha π
well I can't fix that :)
It had been a while since I last looked at the source of Rick's project... At least boot-tools-deps
is archived now so folks will be discouraged from using it π
For a maven repo with a self-signed SSL cert, lein
had me add the path to my system's ca-bundle.crt
in profiles.clj / :user / :certificates. What do I do with tools.deps to make that work?
Up until now I've been able to forget about our internal maven server and just use :git/url, but there's a java project out there (https://github.com/entropia/libsocket-can-java) that never released to maven central that we had to build and host ourselves.
nothing in tools.deps that is similar. what happens if you try it?
error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: Error building classpath. Failed to read artifact descriptor for de.entropia:libsocket-can-java:jar:0.3.0
...
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
It might be my OS configuration, I'm looking into it.usually you would update cacert in your Java installation for this I think
that's probably enough to google for how to do it
Iβm trying to get rid of brew in a Mac environment and trying the
script on Mac.
Itβs crashing on:
install: illegal option -- D
Any workarounds for this not involving brew?you can also just look at what the brew script does (which is largely to put the tar in a place and run its own variant of the install script)
it basically downloads https://download.clojure.org/install/clojure-tools-1.10.0.442.tar.gz, expands, cds into clojure-tools, and runs install.sh prefix
from it
I guess it matters where it downloads and does that stuff and that's the env brew provides
ultimately there is clj/clojure, a jar file, deps.edn file, etc and it's just a matter of putting those all in the right places and pointing at each other
Is there a way to set warn-on-reflection true globally in tools.deps, some trick that someone has found out?
I think thereβs a system property for that? Not at a computer to look it up.
off-topic, I'm in the process of trying to get standalone jar to run, is it safe to ignore loop/recur symbol warnings that end with Auto-boxing loop arg: some-symbol
?
Depends whether you care about perf
there's a ticket about this https://clojure.atlassian.net/browse/CLJ-2328
Looks good as far as I remember off the top of my head
Oh yeah, so then no :)