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

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?

It's still happening after updating too.

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

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

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

https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/tools-deps/near/159950271

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

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)

is ssh-agent running?

yes

(I just confirmed by starting it, same failure)

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

I assume you can git clone with that key

yep

Do you have entries in .ssh/config ?

Sometime jsch tries to read those instead of the ssh agent

some tips at https://clojure.atlassian.net/browse/TDEPS-91

I do, are they safe to paste?

Yes

It’s usually just file names

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

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

Host 
  HostName 
  User admin
  IdentityFile ~/.ssh/id_rsa_jplane

yeah, remove the IdentityFile line in first block

Comment out the first block

Hey, it works!

(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

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

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

@alexmiller I managed to wrangle a stacktrace https://github.com/juxt/pack.alpha/issues/64#issuecomment-538061024

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

@joe.lane JSch is going to be a constant source of headaches

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

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

Is it crossing a class loader boundary perhaps?

yeah, must be same class loaded from different loader

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

or is this just setting up capsule stuff

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

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

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.

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

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

wow

that happens a lot with long lines

probably a method to constrain it. haven't looked

long like 10MB lines, in my experience

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

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

I have no idea

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

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:

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

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

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

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

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

duplicates looking likely

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

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.

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.

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

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.