Handle :repositories containing {:username :env/foo, :password :env/bar}

[arohner]

This calls leiningen.core.user/resolve-credentials on repositories. It fixes a bug

where if you have in your project.clj

:repositories {"a-repo" {:url "https://my-repo.com"                        
                                   :username :env/foo
                                   :password :env/bar}}

you'll get this stacktrace when running lein npm install

java.lang.IllegalArgumentException: No matching ctor found for class org.sonatype.aether.repository.Authentication
 at clojure.lang.Reflector.invokeConstructor (Reflector.java:183)
    cemerick.pomegranate.aether$set_authentication.invoke (aether.clj:165)
    cemerick.pomegranate.aether$make_repository.invoke (aether.clj:185)
    cemerick.pomegranate.aether$resolve_dependencies_STAR_$fn__194.invoke (aether.clj:712)
    clojure.core$map$fn__4245.invoke (core.clj:2557)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59)
    clojure.lang.ChunkedCons.next (ChunkedCons.java:43)
    clojure.lang.PersistentVector.create (PersistentVector.java:51)
    clojure.lang.LazilyPersistentVector.create (LazilyPersistentVector.java:31)
    clojure.core$vec.invoke (core.clj:354)
    cemerick.pomegranate.aether$resolve_dependencies_STAR_.doInvoke (aether.clj:712)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invoke (core.clj:624)
    cemerick.pomegranate.aether$resolve_dependencies.doInvoke (aether.clj:729)
    clojure.lang.RestFn.invoke (RestFn.java:457)
    leiningen.npm.deps$resolve_in_jar_deps.invoke (deps.clj:62)
    leiningen.npm.deps$resolve_node_deps.invoke (deps.clj:81)
    leiningen.npm.deps$resolve_node_deps.invoke (deps.clj:85)
    leiningen.npm$project__GT_package.invoke (npm.clj:60)
    leiningen.npm$npm.doInvoke (npm.clj:101)
    clojure.lang.RestFn.invoke (RestFn.java:423)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invoke (core.clj:626)
    leiningen.core.main$partial_task$fn__4230.doInvoke (main.clj:234)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invoke (core.clj:626)
    leiningen.core.main$apply_task.invoke (main.clj:281)
    lein_environ.plugin$write_env_to_file.invoke (plugin.clj:11)
    clojure.lang.Var.invoke (Var.java:394)
    clojure.lang.AFn.applyToHelper (AFn.java:165)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invoke (core.clj:626)
    robert.hooke$compose_hooks$fn__9820.doInvoke (hooke.clj:40)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invoke (core.clj:624)
    robert.hooke$run_hooks.invoke (hooke.clj:46)
    robert.hooke$prepare_for_hooks$fn__9825$fn__9826.doInvoke (hooke.clj:54)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.invoke (RestFn.java:436)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:287)
    leiningen.core.main$_main$fn__4295.invoke (main.clj:357)
    leiningen.core.main$_main.doInvoke (main.clj:344)
    clojure.lang.RestFn.invoke (RestFn.java:421)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invoke (core.clj:624)
    clojure.main$main_opt.invoke (main.clj:315)
    clojure.main$main.doInvoke (main.clj:420)
    clojure.lang.RestFn.invoke (RestFn.java:457)
    clojure.lang.Var.invoke (Var.java:394)
    clojure.lang.AFn.applyToHelper (AFn.java:165)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

[RyanMcG]

I think I'd prefer if we explicitly required leningen.core.user, instead of just assuming it was loaded. Thoughts?

[bodil]

iirc, the potential absence of the namespace will be noticed at compile time anyway?

[RyanMcG]

Ah, you are probably right. I suppose it doesn't matter then. I could still make the argument from a readability perspective. Typically one would determine what libraries a namespace depends on by simply looking at the usage of the ns macro at the top of the file.

I'm fine with it as is though.

[sundbry]

Bump! Having the same issue here.

[RyanMcG]

@sundbry thanks for the ping.
@arohner did you look into correcting the value passed into resolve-repositories?

[arohner]

@RyanMcG you were right that resolve-repos takes the repositories, and not a project. The patch worked for me though, because it had the side-effect of replacing :repositories with the empty map. This avoided the original bug because maven repos aren't necessary for resolving npm packages.

I guess the larger question for me is, why does npm.deps spend so much effort with mvn repos?

[RyanMcG]

Don't modify project.clj unless you need to. Definitely don't change the project name or version number.

[RyanMcG]

I guess the larger question for me is, why does npm.deps spend so much effort with mvn repos?

Some recursion is done looking at your dependencies lein-npm dependencies. At least I believe that is what you are referring to.

[danielcompton]

Is there anything I can do to help get this merged? This bit me in the butt today.

[RyanMcG]

@danielcompton I'd been hoping that @arohner would come back so I could merge his stuff. I'll try and get this merged in when I get home today if @arohner doesn't beat me to it.

[RyanMcG]

This will be in 0.5.1. The version bump is already done, but I have been unable to deploy because I don't have access to my public key at the moment (this is very silly and I apologize). I'll make sure I figure how to sync it better across my devices.