Fork me on GitHub
#tools-deps
<
2019-05-22
>
hlolli00:05:30

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?

seancorfield00:05:08

@hlolli That's the easiest (and only supported) way for tooling to get the list of system, user, and local deps.edn files.

seancorfield00:05:56

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.

hlolli00:05:35

yes, easy to fix, but this makes releasing libraries with lein+tools.deps a no-go

seancorfield00:05:54

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.

hlolli00:05:55

I wonder if the function for describe wasn't originally written in clojure?

hlolli00:05:19

yes I guess so, like I said, late to realize that limitation πŸ™‚

seancorfield00:05:40

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.

hlolli00:05:03

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.

seancorfield00:05:01

At this point, it's pretty fixed in stone that it's going to shell out to clojure I think.

seancorfield00:05:23

That's why there's been so much work done on getting a clojure command working on Windows (via PowerShell).

seancorfield00:05:48

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.

hlolli00:05:48

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.

seancorfield01:05:38

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

seancorfield01:05:11

We switched our entire stack from Boot to clj/`deps.edn` last year. We've been very happy with that.

hlolli01:05:53

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

seancorfield01:05:23

If folks are happy with lein/`boot`, stay with lein/`boot`. Don't try to blend them tho' πŸ™‚

hlolli01:05:51

yes, I agree with the fact that the my world would be a better place if everybody used tools.deps

Alex Miller (Clojure team)01:05:07

-Sdescribe doesn't need to shell out if there isn't an install deps.edn, which may happen

hlolli01:05:52

ah that explains! the mix here of project.clj and deps.edn in a directory is probably confusing

seancorfield01:05:41

@alexmiller Tooling that calls clojure-env depends on tools.deps shelling out -- to run clojure -Sdescribe.

seancorfield01:05:56

Are you saying that tooling could figure out it doesn't need to call clojure-env?

seancorfield01:05:16

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

seancorfield01:05:38

(it doesn't mean the project is relying on Leiningen using tools.deps)

Alex Miller (Clojure team)01:05:41

well what are you calling clojure-env for?

Alex Miller (Clojure team)01:05:52

I assume the locations of the deps.edn files

seancorfield01:05:10

Right, so that those can be passed back in to tools.deps...

Alex Miller (Clojure team)01:05:28

there are 3 - install (goes away), ~/.clojure (deterministic based on env vars), current directory

Alex Miller (Clojure team)01:05:31

the first one is the hard one

seancorfield01:05:29

Ah, and you're going to fold the system/install one back into the library, right?

Alex Miller (Clojure team)01:05:56

this also removes the biggest pain in the ass in the installer which is also finding that path

Alex Miller (Clojure team)01:05:04

well, maybe it's the path to the jar itself

seancorfield01:05:04

(which is what I had originally done with boot-tools-deps -- baked in a copy of it from the Clojure tools repo πŸ™‚ )

Alex Miller (Clojure team)01:05:25

yeah. doesn't even need to be a file, could just hardcode parts of it

hlolli01:05:27

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.

Alex Miller (Clojure team)01:05:15

the root deps.edn is just:

Alex Miller (Clojure team)01:05:18

{
  :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 ""}
  }
}

seancorfield01:05:42

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! πŸ™‚

seancorfield01:05:11

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

Alex Miller (Clojure team)01:05:38

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

Alex Miller (Clojure team)01:05:18

which is admittedly more work, but is also something that does not depend on anyone else doing anything

seancorfield01:05:18

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:

Alex Miller (Clojure team)01:05:42

I'll just change it to return "thppppt"

😸 4
hlolli01:05:04

@seancorfield amazing, thanks, my error is actually coming from right there but not tools.deps.alpha πŸ˜„

hlolli01:05:14

the windows cmd is hard to read

Alex Miller (Clojure team)01:05:34

well I can't fix that :)

hlolli01:05:44

exactly πŸ™‚

seancorfield01:05:59

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 πŸ™‚

Alex Whitt15:05:22

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?

Alex Whitt15:05:46

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.

Alex Miller (Clojure team)15:05:19

nothing in tools.deps that is similar. what happens if you try it?

Alex Whitt16:05:47

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.

Alex Miller (Clojure team)16:05:57

usually you would update cacert in your Java installation for this I think

Alex Miller (Clojure team)16:05:04

that's probably enough to google for how to do it

borkdude20:05:42

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?

borkdude20:05:06

the reason is that brew from scratch is terribly slow on CI

ghadi20:05:37

you can cp + chmod instead of install

ghadi20:05:01

you can mimic the "spirit" of the install script

borkdude20:05:20

yeah, that works πŸ™‚

Alex Miller (Clojure team)20:05:21

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)

borkdude20:05:43

that works too

Alex Miller (Clojure team)20:05:56

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

borkdude20:05:24

that sounds easy enough, ok

Alex Miller (Clojure team)20:05:15

I guess it matters where it downloads and does that stuff and that's the env brew provides

Alex Miller (Clojure team)20:05:27

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

borkdude21:05:07

got it working now

borkdude21:05:23

clojure now installs in 0 seconds in CI instead of 5 minutes πŸ˜‰

hlolli23:05:17

Is there a way to set warn-on-reflection true globally in tools.deps, some trick that someone has found out?

hlolli23:05:47

nevermind, I should get used to just keeping it in my clojure files

Alex Miller (Clojure team)23:05:40

I think there’s a system property for that? Not at a computer to look it up.

hlolli23:05:06

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 ?

Alex Miller (Clojure team)23:05:49

Depends whether you care about perf

hlolli23:05:53

ok, so it's possible to remove these reflections, my misunderstanding

hlolli23:05:02

this looks about right? :jvm-opts ["-Dclojure.compile.warn-on-reflection=true"]

Alex Miller (Clojure team)23:05:15

Looks good as far as I remember off the top of my head

hlolli23:05:56

I'm running compile/compile, and I only hear crickets