Fork me on GitHub
#tools-deps
<
2019-08-07
>
cfleming01:08:13

If I want to use a fork of Clojure with deps, can I exclude the clojure version pulled in from the system deps.edn somehow?

seancorfield04:08:31

@cfleming If your local deps.edn file has that (local?) Clojure in :deps directly, it should override the system deps anyway?

Alex Miller (Clojure team)05:08:45

assuming you have built and installed that fork locally in Maven so that it's artifact id is still org.clojure/clojure

Alex Miller (Clojure team)05:08:12

if you want to call it something else (or use as a git or local dep), then no, that is not currently supported

Alex Miller (Clojure team)05:08:55

that's not really intentional just kind of a consequence of various assumptions

cfleming05:08:21

Yeah, I changed the artifact ID to reduce confusion.

Alex Miller (Clojure team)05:08:34

top-level exclusions would possibly help with this but not there yet

cfleming05:08:45

Ok, I think it would be kind of a pain to use due to… right, the lack of that.

cfleming05:08:00

I’ll stick with Maven for now then, thanks!

cfleming05:08:26

Actually, if I had the forked jar in a lib dir, and used :deps {org.clojure/clojure {:local/root "lib/clojure-1.10.1.jar"}}, that should work, right?

cfleming05:08:52

i.e. deps will assume that the artifact ID is whatever I tell it.

cfleming05:08:14

And that will override the official one.

Alex Miller (Clojure team)05:08:42

there are some issues with overriding a maven dep with a git / local dep

Alex Miller (Clojure team)05:08:54

so I don't think it will work

cfleming05:08:09

Ok, thanks. I’ll ditch that idea for now, then.

Alex Miller (Clojure team)05:08:27

that one kind of bugs me. I haven't had a chance to look at it yet

Alex Miller (Clojure team)05:08:44

part of it is the version comparison across dep types

Alex Miller (Clojure team)05:08:03

but on override that shouldn't matter

👍 4
hkupty20:08:13

Hi folks, has anyone successfully used tools.deps w/ git repos on private repositories?

hkupty21:08:24

As the maintainer of both tools.deps and tools.gitlibs, I expected a more user-friendly answer from you.

Alex Miller (Clojure team)21:08:11

Sorry, was just answering your question. Was hard to provide any additional detail without any problem description

hkupty21:08:27

I'm having issues w/ unknown host key if I use git@... or I need to provide credentials if I use the https form, which I obviously won't do, since I'm not comiting credentials on the repo

hkupty21:08:46

Is there any docs on how to get over that?

Alex Miller (Clojure team)21:08:42

can you share the error message or more info about your setup and what you're doing?

Alex Miller (Clojure team)21:08:28

https auth is not currently supported so you'll need to use ssh

hkupty21:08:11

I'm running from Fedora 30, very basic setup. The error code I get is:

Execution error (JSchException) at com.jcraft.jsch.Session/checkHost (Session.java:805).\nUnknownHostKey: . RSA key fingerprint is .....
It came from a direct invocation of tools.deps respolve-deps:
(deps/resolve-deps {:deps {'project {:git/url ":repo"
                                             :sha "commit-sha"}}}
                       {})

hkupty21:08:48

I'm running the repl from a session where I've added the keys to ssh-agent, so I assume this step is done.

carkh21:08:17

did you add the host to your .ssh/known_hosts ?

hkupty21:08:47

Hum... I think I know what could be the issue.

hkupty21:08:02

I'm using ED25519 instead of RSA for gitlab.

ghadi21:08:59

ssh-keyscan -t rsa,ed25519 >> ~/.ssh/known_hosts

ghadi21:08:20

that will seed UnknownHostKeys ^ into your config

ghadi21:08:04

ED25519 on the user identity file is fine (when using an agent) @ingvij the error you're pasting is an rsa host key, a different kind of key

hkupty21:08:41

I see. Fine then, I'll try both approaches and I'll post the results back here.

hkupty21:08:21

ssh-keyscan and the link @alexmiller posted

ghadi21:08:24

the article @alexmiller posted seems to use the same exact thing I'm describing

hkupty21:08:52

ahh, sorry. I hadn't read the article yet

ghadi21:08:53

since clojure deps.edn is not terminal interactive, the .ssh/known_hosts file needs the host key

hkupty21:08:14

Right, that makes sense.

ghadi21:08:02

(but this approach is a bit insecure because no one is validating the fingerprints...)

ghadi21:08:31

(then again most people type Yes anyways when ssh prompts you..)

hkupty21:08:26

Should work fine as a workaround I suppose.

hkupty21:08:02

That worked for checking the dependency, but I'm getting a MetadataNotFoundException now. I'll double-check everything, specially the dependency itself. Thanks for the help @ghadi and @alexmiller.

Alex Miller (Clojure team)21:08:37

if you can share more info, might have some idea what that is, but I don't even know what layer of the stack it's from

Alex Miller (Clojure team)21:08:23

just in general, providing information at the beginning lets people help you more efficiently, and we're all doing this for free, in spare time

👍 4
hkupty21:08:48

Execution error (MetadataNotFoundException) at org.eclipse.aether.internal.impl.DefaultMetadataResolver/resolve (DefaultMetadataResolver.java:233).\nCould not find metadata org.clojure:clojure/maven-metadata.xml in local (/home/hkupty/.m2/repository)

hkupty21:08:16

The stacktrace from tools.deps:

[[org.eclipse.aether.internal.impl.DefaultMetadataResolver
    resolve
    "DefaultMetadataResolver.java"
    233]
   [org.eclipse.aether.internal.impl.DefaultMetadataResolver
    resolveMetadata
    "DefaultMetadataResolver.java"
    191]
   [org.apache.maven.repository.internal.DefaultVersionResolver
    resolveVersion
    "DefaultVersionResolver.java"
    233]
   [org.eclipse.aether.internal.impl.DefaultRepositorySystem
    resolveVersion
    "DefaultRepositorySystem.java"
    238]
   [clojure.tools.deps.alpha.extensions.maven$eval362$fn__365
    invoke
    "maven.clj"
    40]
   [clojure.lang.MultiFn invoke "MultiFn.java" 239]
   [clojure.tools.deps.alpha$canonicalize_deps$fn__761
    invoke
    "alpha.clj"
    68]
   [clojure.core.protocols$fn__8159 invokeStatic "protocols.clj" 168]
   [clojure.core.protocols$fn__8159 invoke "protocols.clj" 124]
   [clojure.core.protocols$fn__8114$G__8109__8123
    invoke
    "protocols.clj"
    19]
   [clojure.core.protocols$seq_reduce invokeStatic "protocols.clj" 31]
   [clojure.core.protocols$fn__8144 invokeStatic "protocols.clj" 75]
   [clojure.core.protocols$fn__8144 invoke "protocols.clj" 75]
   [clojure.core.protocols$fn__8088$G__8083__8101
    invoke
    "protocols.clj"
    13]
   [clojure.core$reduce invokeStatic "core.clj" 6828]
   [clojure.core$reduce invoke "core.clj" 6810]
   [clojure.tools.deps.alpha$canonicalize_deps
    invokeStatic
    "alpha.clj"
    67]
   [clojure.tools.deps.alpha$canonicalize_deps invoke "alpha.clj" 65]
   [clojure.tools.deps.alpha$expand_deps$fn__787
    invoke
    "alpha.clj"
    184]
   [clojure.tools.deps.alpha$expand_deps invokeStatic "alpha.clj" 183]
   [clojure.tools.deps.alpha$expand_deps invoke "alpha.clj" 164]
   [clojure.tools.deps.alpha$resolve_deps invokeStatic "alpha.clj" 231]
   [clojure.tools.deps.alpha$resolve_deps invoke "alpha.clj" 213]

Alex Miller (Clojure team)21:08:49

org.clojure:clojure/maven-metadata.xml looks weird

Alex Miller (Clojure team)21:08:56

maybe bad format in your deps.edn?

Alex Miller (Clojure team)21:08:08

org.clojure:clojure when should be org.clojure/clojure maybe?

hkupty21:08:34

I checked the dependency, it's clojure version was RELEASE as it comes from default when you bootstrap a project w/ https://github.com/seancorfield/clj-new

ghadi21:08:30

you should choose an explicit version for clojure

ghadi21:08:42

@alexmiller maybe -Sresolve can rewrite symbolic maven things, too

hkupty21:08:02

I know. this is still on very initial stages, just testing really..

hkupty21:08:24

That's why I didn't care too much about it. Just pinned the version.

Alex Miller (Clojure team)21:08:41

re RELEASE, agreed, bleh

Alex Miller (Clojure team)21:08:28

RELEASE is not officially supported in deps.edn

Alex Miller (Clojure team)21:08:58

I've let it continue to work as it's sometimes a good hack, but shouldn't be enshrining it

Alex Miller (Clojure team)21:08:08

-Sresolve is going to go away (move into an external tool)

hkupty21:08:57

I moved past that error, now yet another one bothering me. A dependency of a dependency is not being resolved, whereas if I run clj on the library I'm trying to import, it works fine:

Syntax error (ExceptionInfo) compiling at (cli/ops.clj:5:1).\nUnable to resolve io.grpc/grpc-core version: [1.17.1]
When I run the repl directly it works, if I call this it fails:
(deps/resolve-deps {:deps {'io.etcd/jetcd-core {:mvn/version "0.3.0"}}}
                   {})

hkupty21:08:13

I don't want to keep you involved in the debugging unless you want to, I just keep posting since I think those might be relevant. I'd understand if you'd rather want me to open an issue.

hkupty21:08:03

which, btw, I'll do for clj-new so new projects are not created w/ RELEASE on clojure version.

hiredman21:08:12

that is a syntax error, not related to deps at all

hiredman21:08:54

I would dig in to cli/ops.clj on the given line number, likely something isn't being quoted correctly

hkupty22:08:51

that particular invocation is this one:

(deps/resolve-deps {:deps {'io.etcd/jetcd-core {:mvn/version "0.3.0"}}}
                   {})
I believe this might be due to some parsing from pom.xml instead of deps.edn maybe

hiredman22:08:10

on pardon me, that does come from tools deps, I wonder why it is categorized as a syntax error

hkupty22:08:07

I assume it's complaining about the dependency declaration syntax, as it expects ns:symbol:jar:version where version is a string, but instead it gets a list.

Alex Miller (Clojure team)22:08:14

@U0NCTKEV8 the syntax thing is a bug, I have a patch pending for that

hiredman22:08:22

clj -Sdeps "{:deps {io.etcd/jetcd-core {:mvn/version \"0.3.0\"}}}" might give you a clearer error

hiredman22:08:08

it looks like something depends on an artifact that is not in maven central

Alex Miller (Clojure team)22:08:27

if you're calling this with tools.deps directly, you need to pass it the repos

Alex Miller (Clojure team)22:08:39

clj provides those, but tools.deps does not (automatically)

hkupty22:08:40

I'll check that. However, the thing is I can do (deps/resolve-deps {:deps {'io.grpc/grpc-core {:mvn/version "1.17.1"}}} {})

hiredman22:08:09

but that is a different thing

Alex Miller (Clojure team)22:08:13

b/c you have it locally

hkupty22:08:13

But I can't do the same for io.etcd/jetcd-core, which fails on this very same dependency.

hiredman22:08:28

it does not for me, for me it fails to find io.netty:netty-codec-http2:jar:[4.1.30.Final] in central

hkupty22:08:03

Right. I got a Syntax error (ExceptionInfo) compiling at (cli/ops.clj:5:1).\nCould not find artifact io.grpc:grpc-core:jar:1.17.1 after moving my ~/.m2 to ~/.m2-bkp`.

hkupty22:08:21

So I'll make sure to add the extra repositories

hiredman22:08:08

it would be great if you could try the command line call to clj

hiredman22:08:12

it looks like the place in deps where that exception is thrown is if the dep is either a version range or an alias like LATEST or RELEASE

hiredman22:08:49

so my guess something in jetcd is changing how maven attempts to resolve an alias or a range in io.grpc's dependencies

hkupty22:08:10

I could make it work by adding "central" {...} to :mvn/repos

hkupty22:08:23

that solves everything

hiredman22:08:10

hrmm, I am still getting errors, and it has changed to different artifacts not being found in central now 😞

hiredman22:08:59

but I am not using jetcd-core so no big deal

hkupty22:08:43

😅 Thanks to you both for all the help and guidance 🙂

seancorfield22:08:59

In light of continued complaints about the use of "RELEASE" in projects created by clj-new ... seancorfield/clj-new {:mvn/version "0.7.7"} pins these to 1.10.1 (for Clojure) and 0.10.0-RC1 (for test.check). You're welcome 🙂

thanks3 8
seancorfield22:08:57

Bear in mind that lein new, boot new, and clj-new all look for templates themselves (on Clojars/Central) using "RELEASE" under the hood unless you specify a template version to use (which almost no one does).

andy.fingerhut23:08:27

This is not a critical question in any way, but was curious whether folks had any recommendations on creating a deps.edn file for a library that has Clojure-specific and ClojureScript-specific flavors in the same git repo, e.g. core.rrb-vector is the one I have in mind. One thought: create a deps.edn that has almost 0 dependencies when no aliases are specified, and has a :clj alias for Clojure dependencies/paths, and a :cljs alias for ClojureScript dependencies/paths. Second thought: Two separate deps.edn files, except there is only one root directory file named deps.edn available.

andy.fingerhut23:08:08

Third thought: two separate git repos, one for each variant?