Fork me on GitHub
#tools-deps
<
2019-10-03
>
dominicm16:10:06

@alexmiller bit of a weird one https://github.com/juxt/pack.alpha/issues/64 no repro yet exactly, but it looks like RepositorySystem is coming back as nil. I don't suppose you're clued up on this and can think of an obvious cause?

alexmiller17:10:29

I looked at that when it was filed as it was mentioned here too. It's weird, don't know what to make of it. I think from the stack this pre-dates the session cache additions?

dominicm17:10:24

It's still happening after updating too.

dominicm17:10:54

Digging in, the impl of the service locator does attempt to add the repository system, so that should be there.

dominicm17:10:41

Bumping from 1.1.1 of the maven dependencies to 1.4.1 doesn't fix it either.

dominicm17:10:45

this is the problem with service locators. All the damn coupling.

Joe Lane17:10:13

Hey friends, I'm having an issue cloning my own private github repo with tools deps. Even though I'm able to clone the repo with the ssh url into a local tmp directory, JGit is still telling me that Caused by: org.eclipse.jgit.errors.TransportException: [email protected]:Dept24c/random.git: USERAUTH fail. I'm on a mac with these version numbers:

Joes-MacBook-Pro:snapestry-ion magemasher$ clj -Sverbose
version      = 1.10.1.469
install_dir  = /usr/local/Cellar/clojure/1.10.1.469
config_dir   = /Users/magemasher/.clojure
config_paths = /usr/local/Cellar/clojure/1.10.1.469/deps.edn /Users/magemasher/.clojure/deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache/479583893.cp
The ssh key I have on github matches this key below:
ssh-add -l -E md5
4096 MD5:10:ef:06:6b:9b:94:86:fc:06:83:9f:17:0a:8c:bb:10 /Users/magemasher/.ssh/id_rsa_jplane (RSA)
Does anybody have any ideas? I'm really stumped here.

alexmiller17:10:32

is ssh-agent running?

Joe Lane17:10:39

(I just confirmed by starting it, same failure)

alexmiller18:10:33

there are some known failure modes with host key algorithms etc, but this doesn't really look like that

alexmiller18:10:42

I assume you can git clone with that key

ghadi18:10:09

Do you have entries in .ssh/config ?

ghadi18:10:26

Sometime jsch tries to read those instead of the ssh agent

Joe Lane18:10:03

I do, are they safe to paste?

ghadi18:10:26

It’s usually just file names

alexmiller18:10:32

there's one like IdentityKey or something that might need to be removed

Joe Lane18:10:45

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa_jplane
  IdentitiesOnly yes

Host 
  HostName 
  User admin
  IdentityFile ~/.ssh/id_rsa_jplane

alexmiller18:10:01

yeah, remove the IdentityFile line in first block

ghadi18:10:02

Comment out the first block

Joe Lane18:10:45

Hey, it works!

Joe Lane18:10:42

(commenting out just the IdentityFile) So, the reason I had that line in there in the first place was because of these instructions. https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

Joe Lane18:10:34

So, while I'm glad this was fixed for me, are the github instructions conflicting with what Jsch needs?

Joe Lane18:10:07

Either way, thank you both for your assistance! I see similar advice was given by Alex on the jira issue.

dominicm18:10:43

The problem is, I can't figure out what would set a version resolver! There's nothing in the default service locator code.

ghadi18:10:40

@lanejo01 JSch is going to be a constant source of headaches

dominicm18:10:35

Okay. Figured out what sets the version resolver, but I don't understand how I'm getting java.lang.ClassCastException: Cannot cast org.apache.maven.repository.internal.DefaultVersionResolver to org.eclipse.aether.impl.VersionResolver when defaultversionresolver is like this:

public class DefaultVersionResolver
    implements VersionResolver, Service

dominicm18:10:39

Doesn't that explicitly state that it's a VersionResolver?!

seancorfield18:10:35

Is it crossing a class loader boundary perhaps?

alexmiller18:10:40

yeah, must be same class loaded from different loader

alexmiller18:10:39

looks like you're buried in some capsule stuff - doesn't that do weird things with classloaders?

alexmiller18:10:09

or is this just setting up capsule stuff

alexmiller19:10:50

I'm not sure what the setup is, but there must be same class available via different loaders somehow here

dominicm19:10:11

This is setting up capsule stuff, so no classloaders involved here yet.

dominicm19:10:32

capsule is very good on the classloader front fwiw btw. It just extracts to a directory and runs it, much like leiningen. OneJar is the classloader one.

dominicm19:10:58

I'll see if I can make this a minimal repro at least. Remove pack from the equation.

dominicm19:10:25

rlwrap: Oops, crashed (caught SIGABRT) - this should not have happened!If you need a core dump, re-configure with --enable-debug and rebuildResetting terminal and cleaning up...
Today is not my day apparently! 🙂

ghadi19:10:40

that happens a lot with long lines

ghadi19:10:09

probably a method to constrain it. haven't looked

ghadi19:10:20

long like 10MB lines, in my experience

andy.fingerhut19:10:09

I sometimes idly wonder how many different behaviors exist among line-based utility programs for very very long lines.

dominicm20:10:46

What I don't understand is how simply commenting out oz would change things. How does that cause a classloader?!

alexmiller20:10:10

I have no idea

alexmiller20:10:56

I don't have a theory for why this is happening, just trying to work backward from the evidence

dominicm21:10:42

I can't create a minimal repro either. Taking the exact pack code and placing it in another project stops it from happening... :thinking_face:

alexmiller21:10:51

can you get pack out of it? Just call tools.deps with oz stuff?

alexmiller21:10:59

I can't remember if I did that when it was logged or not

dominicm21:10:44

Doing that doesn't throw. There's something contextual/environmental that I am not accounting for.

alexmiller21:10:36

are you running via clj? if so, what's the classpath? Are there any uberjars such that same class has two possible sources?

dominicm21:10:24

Running via clj. The classpath is pretty big because of oz.

dominicm21:10:58

duplicates looking likely

dominicm21:10:14

clojure -Spath -A:pack:packit | (while IFS= read -rd: line; do jar tf "${line}"; done) | sort | uniq -d I did this and got results

dominicm21:10:49

I know why my repro isn't working, it's because I'm not co-locating oz and t.d.a on the classpath in my repro, but I am when I load pack into an existing project. That's also why this happens when used with add-lib.

dominicm21:10:28

It's nothing to do with dependency resolution (not really anyway). It's to do with the classpath tda is running under. I saw maven duplicates with the above classpath, so I'm guessing that's the root cause. Although I've never seen issues like this where one wins out over the other in different places.

hiredman22:10:14

the classpath isn't canonical, classloaders are, the classpath is interpreted by some classloader, so if some wants a classloader that behaves sort of like the system classloader (or whatever the root classloader is called these days) it can make a classloader that interprets the classpath but has a slightly different behavior

alexmiller22:10:33

Maven has all kinds of magic dependency injection and it’s entirely possible there is some service config somewhere that is giving weird behavior. Usually I just avoid using all of that stuff when I call the maven APIs but it’s surprisingly invasive.