Giter Site home page Giter Site logo

rickmoynihan / lein-tools-deps Goto Github PK

View Code? Open in Web Editor NEW
167.0 7.0 20.0 128 KB

A leiningen plugin that lets you share tools.deps.alpha dependencies in your leiningen project

License: Eclipse Public License 1.0

Clojure 100.00%
clojure leiningen tools-deps

lein-tools-deps's Introduction

lein-tools-deps

WARNING: This project is unmaintained and targets a 4y/old version of tools.deps

Clojars Project

Build Status

A leiningen plugin that lets you share tools.deps.alpha deps.edn dependencies with your leiningen project build.

Do you really want to use this?

Probably not, it has been over 4 years since its last update; and is hugely behind on changes in tools.deps. If you think you need to use this, then you should expect to fork it and maintain it going forward, or if you require git/deps use tools.build instead.

If you plan on forking this, then you will probably want to update to a more recent version of tools.deps, and I'd also suggest at least fixing this issue if you intend to also use it for library development.

lein-tools-deps has to square the circle between leiningen & maven's dependency resolution algorithm and that used by tools.deps. Leiningen and Maven, when there is a conflict always pick the version that is closest to the root of the dependency tree; where as tools.deps always picks the newest.

In order to square this circle, lein-tools-deps resolves all dependencies with tools.deps and flattens the tree before inserting it into lein's :dependencies vector. This guarantees the resolution is the same as tools.deps would give; however it has the unfortunate effect of flattening your libraries dependencies for consumers of your library. This makes it significantly harder for consumers to use :exclusions and overrides when they get a conflict on a transitive dependency brought in by your library.

Why use leiningen and deps.edn?

The Clojure 1.9.0 command line tools bring a host of new benefits to the Clojure practitioner. In particular native support for dependencies hosted in git repositories (and not deployed as maven artifacts), faster startup times for project REPLs, and easier ways to script with Clojure and define multi-project projects; all whilst providing a purely declarative data format in the form of deps.edn files.

However at its core deps.edn and the CLI tools are just a simple system that provide better facilities for resolving dependencies and building a java classpath. They actively avoid being a build tool, and consequently can't be used in isolation to build a project, :aot compile it, uberjar it, etc...

Leiningen is the incumbent build tool for Clojure projects. It's well supported, with a thriving plugin ecosystem, and is the default choice in the Clojure world if you need to build an application or deploy a library. It's easy to get started with and is great if you have a pro-forma project; which doesn't need much custom build-scripting.

lein-tools-deps teaches Leiningen to take its :dependencies from your deps.edn files, which means you can get the best of both worlds. You can use clj and deps.edn to take advantage of deps.edn sub-projects, located on the local filesystem (:local/root) and in git repositories (:git/url) or make use of standard maven dependencies (:mvn/version).

lein-tools-deps will let you replace your leiningen :dependencies entirely with those from deps.edn meaning you don't need to repeat yourself. Likewise for deps.edn projects if you need to start :aot compiling, uberjaring, or integrating with a :cljs-build, you now can.

Essentially lein-tools-deps lets Clojure practitioners use both Leiningen and the clj / deps.edn tools together in the same project.

Why not use boot instead?

Boot is arguably a better choice than Leiningen if you need more bespoke build scripting. However Leiningen projects because of their declarative constraints tend to be more uniform and familiar. Leiningen projects are harder to turn into unique snowflakes, which might be better or worse for you.

If you don't need anything fancy (like a combined Clojurescript/Clojure build) and want to just get started quickly, I'd recommend Leiningen over Boot. If you don't need to :aot, or to build your Clojure at all, and your development environment and prefered tools support it go lightweight and just use clj and deps.edn.

If you want to integrate boot with tools.deps you can via @seancorfield's boot-tools-deps.

Why not just use deps.edn?

If you can do this, consider it, and consider not using lein-tools-deps at all. Yes, I'm saying maybe you don't need this project; even if it is pretty good :-)

deps.edn is starting to grow an ecosystem of tools and whilst they're not yet mature, and the landscape is frequently changing, with various contenders many existing tools such as the Clojurescript compiler, and figwheel-main have native support for deps.edn. Additionally there are new tools such as depstar, pack.alpha, katamari that will work with deps.edn and might be able to build that uberjar for you.

See the tools.deps Tools page for a more complete list of available tooling.

lein-tools-deps is for those who need or want to keep a foot in both camps. Perhaps it's suitable as a stop gap solution for an existing leiningen project, or perhaps members of your team are only just getting used to leiningen, and you don't want to confuse them with another tool or workflow.

Usage

Simply add the following to your plugins and middleware vectors, respectively, in your project.clj:

  :plugins [[lein-tools-deps "0.4.5"]]
  :middleware [lein-tools-deps.plugin/resolve-dependencies-with-deps-edn]

Then set :lein-tools-deps/config to specify which deps.edn files to resolve, we recommend:

:lein-tools-deps/config {:config-files [:install :user :project]}

The keywords :install, :user and :project will be resolved by the plugin. You can also supply your own paths as strings, e.g.

:lein-tools-deps/config {:config-files [:install :user :project "../src/deps.edn"]}

You can now delete your :dependencies vector from project.clj.

Note: With lein-tools-deps 0.3.0-SNAPSHOT and earlier, the config value was a vector and looked like :tools/deps [:install :user :project], as of 0.4.0 it changed to the above map based syntax.

Supported configuration options

:config-files

A vector referencing an ordered collection of deps.edn files that will be used for dependency resolution. Each file should be either a file path string or a special keyword (:install :user or :project). The special :install and :user keys refer to the deps.edn files defined in the installation and user's home .clojure config directories; whilst :project refers to a deps.edn at the root of your leiningen project.

:clojure-executables

A vector of strings identifying possible install locations for the clojure command line tool script. They will be tried in order, with the first match being used. The default is currently set to [/usr/local/bin/clojure]. This is necessary as lein-tools-deps uses the clojure executable to determine some system specific defaults, such as the location of the :install :config-files.

:resolve-aliases

A vector of deps.edn alias names whose :extra-deps, override-deps and :default-deps will be resolved with the same semantics as if they had been used with the -R option to the clj tool.

:classpath-aliases

A vector of deps.edn alias names whose :extra-paths and classpath-overrides will be applied with the same semantics as if they had been used with the -C option to the clj tool.

:aliases

A vector of deps.edn alias names whose values are resolved in the same way as for both :resolve-aliases and classpath-aliases above. Equivalent to the -A option of the clj tool.

Profiles

lein-tools-deps works with Leiningen profiles, allowing you to specify dependencies on a per profile basis. We support the use of any configuration options in Leiningen profiles, which will follow Leiningen's standard meta-merge semantics for each of the configuration options above. Profiles are merged before tools.deps resolution.

E.g.

    :lein-tools-deps/config {:config-files ["foo.edn"]}
    :profiles {:dev {:lein-tools-deps/config ["bar.edn" "baz.edn"]}}

results a logical :config-files value of ["foo.edn" "bar.edn" "baz.edn"] when the :dev profile is used.

Aliases and all other options are resolved in a similar fashion, and support the use of Leiningen's ^:replace/^:displace metadata flags, to control the merge.

One of the benefits of lein-tools-deps is that you can use profiles to group various combinations of :aliases etc under a single profile name.

Prerequisites

You will need the following base dependencies installed:

Project Status

ALPHA because tools.deps is still .alpha.

PRs & ideas for future development welcome.

Please see the issue tracker

With thanks to

  • @HughPowell
  • @mfikes
  • @seancorfield
  • @puredanger
  • @atroche
  • @marco-m

License

Copyright © 2017 Rick Moynihan

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.

lein-tools-deps's People

Contributors

atroche avatar hughpowell avatar lkitching avatar mfikes avatar rickmoynihan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

lein-tools-deps's Issues

Why does `lein ancient` plugin not work

From #tools-deps slack channel:

dorab [4:46 AM]
If I try `lein ancient` after incorporating `lein-tools-deps` in my `project.clj` it always tells me that the artifacts are up-to-date. What do I need to do to get `lein ancient` work with `lein-tools-deps`? Thanks.

hagmonk [6:15 AM]
@dorab because with `lein-tools-deps` you're storing your deps in deps.edn, I'd recommend you use a tool that targets deps.edn directly. So far I only know of https://github.com/Olical/depot, but it works great
Olical/depot
Find newer versions of your dependencies in your deps.edn file
Website
https://clojars.org/olical/depot
Stars
46
Olical/depotMar 21stAdded by GitHub

dorab [4:41 PM]
Thanks!

dorab [4:48 PM]
Did exactly what I wanted.

Make travis use example project as an integration test

It would be good if travis could do an additional integration test, by doing something like the following:

cd example
lein run

And fail on a non-zero exit code.

lein run should be wired up to call foo.core which should be modified to have a -main method and aot compiled with a :gen-class.

foo.core should then require some functions from the criterium dependency, the :local/root depdendency, and the git demo-dep and call them. It should be sufficient for these functions to just be used in the namespace; as the real test is that they're resolved correctly, so we're really just checking that they get compiled.

:mvn/repos not accessible to Leiningen

The data in the :mvn/repos key is not transposed into leiningen :repositories and so can't be accessed. This causes issues when accessing repositories other than maven and clojars, e.g. S3 buckets.

Refactor into 3 namespaces

It seems that it might be beneficial to carve the project up into at least 3 namespaces:

  1. lein-tools-deps.plugin (the main namespace composing the others together)
  2. lein-tools-deps.deps (for manipulatingdeps.edn maps etc)
  3. lein-tools-deps.lein-project (for manipulating lein project maps)

Open to other ideas on it though.

Allow for no project-level deps.edn

If :tools/deps is set to [:system :home] then things should work, but one bit that needs to be revised is this bit of code

(def deps-file (io/file (config-files 2)))

Currently it is assuming config-files is a vector with 3 elements and causes a java.lang.IndexOutOfBoundsException if there is no deps.edn sitting in the working directory.

Interested in maintaining

Hey @RickMoynihan, this looks like a really cool and also important (IMHO) project. Are you still interested in maintaining it and pushing it forward?

If not, I'd love to contribute to making it become a thing. What are your thoughts? Would you prefer to take PRs, or would you prefer to transfer the project to a new owner? (I'd be willing to take it on if so.)

Supporting deps.edn aliases

How should we handle profiles in leiningen and deps.edn aliases?

Could deps.edn aliases be combined into leiningen profiles?

Support leiningen profiles

Ok, I've confirmed that this should already work as leiningen profiles are merged before middlewares run; so the lein-tools-deps middleware should just use the merged (top level) project map.

We should document this in the README.md though.

uberjar question

This is a newbie question, trying to use the lein-tool-deps with my project, but I can't seem to get the uberjar part to work. When I run lein uberjar, I see the target directiory and the SNAPSHOT.jar file, but it just keeps growing and growing. I finally kill it after 10GB or so. When I just use lein dependencies w/o lein-tools-deps, the uberjar is created.... Any idea with what I might be doing wrong?

Here's my project.clj

(defproject dlp-inspect "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  ; NOTE: the deps are managed via deps.edn and the lein-tools-deps plugin...
  ;;:dependencies [[org.clojure/clojure "1.9.0"]
  ;;               [datasplash "0.6.3"]
  ;;               [clj-time "0.15.0"]]
  ;;:dependencies []
  :plugins [[lein-tools-deps "0.4.1"]]
  :middleware [lein-tools-deps.plugin/resolve-dependencies-with-deps-edn]
  :lein-tools-deps/config {:config-files [:install :user :project "./deps.edn"]
                           :clojure-executables ["/usr/local/bin/clojure"]}
  :clean-targets ^{:protect false} [...targets...]
  :profiles {:dev {:global-vars {*warn-on-reflection* false}}}
  :uberjar-name "dlp-inspect.jar"
  :manifest {"Class-Path" "."}
  :jvm-opts ["-Xms2g" "-server" "-Xmx4g"]
  :tar {:uberjar true}
  :jar-exclusions [#".DS_Store"]
  :uberjar-exclusions [#".DS_Store" #"META-INF/*.DSA" #"META-INF/*.RSA" #"META-INF/*.SF" #"META-INF/LICENSE"]
  :min-lein-version "2.8.0"
  :aot :all
  :main dlp-inspect.core)

My deps.edn

{
 :paths ["src" "target" "resources"]
 ;; External dependencies
 :deps          {
                 org.clojure/clojure {:mvn/version "1.9.0"}
                 org.clojure/tools.cli {:mvn/version "0.4.1"}
                 clj-time {:mvn/version "0.15.0"}
                 datasplash {:mvn/version "0.6.3" :exclusions [io.grpc/grpc-core]}}


 :mvn/repos     {"central" {:url "https://repo1.maven.org/maven2/"}
                 "clojars" {:url "https://clojars.org/repo"}}}

Document how to use profiles with lein-tools-deps

We should provide an example of using profiles with lein-tools-deps.

In particular we should remind people how merging happens on the inputs to tools.deps, e.g.

:lein-tools-deps/config {:config-files ["foo.edn"]}
:profiles {:dev {:lein-tools-deps/config ["bar.edn" "baz.edn"]}}

So here when running with the :dev profile the combined :config-files become ["foo.edn" "bar.edn" "baz.edn"]. Likewise aliases and other config will be meta-merged in the same way.

Docs question: to what do the keywords :install :user and :project refer?

The docs suggest a set of keywords to be used in the default configuration:

:lein-tools-deps/config {:config-files [:install :user :project]}

I don't understand -- and I'm by no means a leingen expert -- what these keywords are indicating. I thought they might be a way to refer to the name of deps.edn files that are for some reason named alternately since the docs later say under the :config-files option that values for this option should be:

A vector referencing an ordered collection of deps.edn files that will be used for dependency resolution. Each file should be either a file path string or a special keyword (:install :user or :project).

But then I looked at the example and saw that this suggested config is used and yet the only dependency file is called deps.edn.

I'm sure that there's some fundamental lack of knowledge causing to be confused here, but I wonder if others might also be confused. Is there any way to clarify this?

Can remove Cursive workarounds link

There is a link to IntelliJ Cursive workarounds in the main README.md file. With the latest 0.4.1 release, these workarounds are no longer needed, so this link could be removed.

Plugin doesn't respect PATH

You can't specify clojure in a clojure-executables option. That's because it tries to check the existence of clojure and it is not there, so it throws an error. Why not just execute clojure with clojure.java.shell/sh and if there is an error (check the error code), print full response of an error or throw the full response as an exception.

Fixing the Cursive issue with finding the project deps.edn

From @mfikes's Cursive workarounds gist:

When processing project.clj, Cursive will be running with a working directory such as /Applications/IntelliJ IDEA.app/Contents/bin (i.e. not your project directory). This will cause lein-tools-deps to fail to find project-level deps.edn file

Instead of using the clojure.tools.deps.alpha.reader/clojure-env fn (which uses clojure -Sdescribe under the hood) to get the project deps.edn, is there a way we could use leiningen's knowledge of the location of the project.clj file?

NPE when :project is specified but there's no deps.edn in the project root

> lein deps

java.lang.NullPointerException: null
 at clojure.lang.Reflector.invokeNoArgInstanceMember (Reflector.java:301)
    lein_tools_deps.plugin$resolve_deps$fn__1141.invoke (plugin.clj:76)
    clojure.core$filter$fn__4812.invoke (core.clj:2708)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:521)
    clojure.core$seq__4357.invokeStatic (core.clj:137)
    clojure.core$map$fn__4785.invoke (core.clj:2637)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.Cons.next (Cons.java:39)
    clojure.lang.RT.boundedLength (RT.java:1749)
    clojure.lang.RestFn.applyTo (RestFn.java:130)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    clojure.tools.deps.alpha.reader$merge_deps.invokeStatic (reader.clj:73)
    clojure.tools.deps.alpha.reader$merge_deps.invoke (reader.clj:70)
    clojure.tools.deps.alpha.reader$read_deps.invokeStatic (reader.clj:78)
    clojure.tools.deps.alpha.reader$read_deps.invoke (reader.clj:75)
    lein_tools_deps.plugin$read_all_deps.invokeStatic (plugin.clj:34)
    lein_tools_deps.plugin$read_all_deps.invoke (plugin.clj:33)
    lein_tools_deps.plugin$resolve_deps.invokeStatic (plugin.clj:77)
    lein_tools_deps.plugin$resolve_deps.invoke (plugin.clj:69)

Enhancement: Improve error message if `clojure` can't run

project.clj:

(defproject try-lein-tools-deps "0.1.0-SNAPSHOT"
  :plugins [[lein-tools-deps "0.3.0-SNAPSHOT"]]
  :tools/deps [:system :home :project])

deps.edn (malformed):

{:deps {x}}}
$ lein repl
clojure.lang.ExceptionInfo: Unable to locate Clojure's edn files
 at clojure.core$ex_info.invokeStatic (core.clj:4617)
    clojure.core$ex_info.invoke (core.clj:4617)
    clojure.tools.deps.alpha.reader$scrape_clojure_env.invokeStatic (reader.clj:23)
    clojure.tools.deps.alpha.reader$scrape_clojure_env.invoke (reader.clj:18)
    clojure.lang.AFn.applyToHelper (AFn.java:152)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.core$memoize$fn__5708.doInvoke (core.clj:6107)
    clojure.lang.RestFn.invoke (RestFn.java:397)
    lein_tools_deps.plugin$make_dep_loc_lookup.invokeStatic (plugin.clj:19)
    lein_tools_deps.plugin$make_dep_loc_lookup.invoke (plugin.clj:14)
    lein_tools_deps.plugin$canonicalise_dep_locs.invokeStatic (plugin.clj:28)
    lein_tools_deps.plugin$canonicalise_dep_locs.invoke (plugin.clj:27)
    lein_tools_deps.plugin$middleware.invokeStatic (plugin.clj:93)
    lein_tools_deps.plugin$middleware.invoke (plugin.clj:85)
    clojure.lang.Var.invoke (Var.java:379)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:801)
    leiningen.core.project$apply_middleware.invoke (project.clj:794)
    clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)
    clojure.core.protocols$fn__6750.invokeStatic (protocols.clj:136)
    clojure.core.protocols/fn (protocols.clj:124)
    clojure.core.protocols$fn__6710$G__6705__6719.invoke (protocols.clj:19)
    clojure.core.protocols$seq_reduce.invokeStatic (protocols.clj:31)
    clojure.core.protocols$fn__6738.invokeStatic (protocols.clj:75)
    clojure.core.protocols/fn (protocols.clj:75)
    clojure.core.protocols$fn__6684$G__6679__6697.invoke (protocols.clj:13)
    clojure.core$reduce.invokeStatic (core.clj:6545)
    clojure.core$reduce.invoke (core.clj:6527)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:796)
    leiningen.core.project$apply_middleware.invoke (project.clj:794)
    leiningen.core.project$activate_middleware.invokeStatic (project.clj:828)
    leiningen.core.project$activate_middleware.invoke (project.clj:824)
    leiningen.core.project$init_project.invokeStatic (project.clj:952)
    leiningen.core.project$init_project.invoke (project.clj:942)
    leiningen.core.project$read.invokeStatic (project.clj:1023)
    leiningen.core.project$read.invoke (project.clj:1020)
    leiningen.core.project$read.invokeStatic (project.clj:1024)
    leiningen.core.project$read.invoke (project.clj:1020)
    leiningen.core.main$_main$fn__4734.invoke (main.clj:416)
    leiningen.core.main$_main.invokeStatic (main.clj:411)
    leiningen.core.main$_main.doInvoke (main.clj:408)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.lang.Var.invoke (Var.java:379)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:436)
    clojure.lang.Var.invoke (Var.java:388)
    clojure.lang.AFn.applyToHelper (AFn.java:160)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

If you were to run clojure directly yourself you get more info:

$ clojure
Error building classpath. Map literal must contain an even number of forms
java.lang.RuntimeException: Map literal must contain an even number of forms
	at clojure.lang.Util.runtimeException(Util.java:221)
	at clojure.lang.EdnReader$MapReader.invoke(EdnReader.java:682)
	at clojure.lang.EdnReader.readDelimitedList(EdnReader.java:757)
	at clojure.lang.EdnReader$MapReader.invoke(EdnReader.java:680)
	at clojure.lang.EdnReader.read(EdnReader.java:145)
	at clojure.lang.EdnReader.read(EdnReader.java:111)
	at clojure.edn$read.invokeStatic(edn.clj:35)
	at clojure.edn$read.invoke(edn.clj:14)
	at clojure.tools.deps.alpha.util.io$slurp_edn.invokeStatic(io.clj:29)
	at clojure.tools.deps.alpha.util.io$slurp_edn.invoke(io.clj:22)
	at clojure.tools.deps.alpha.reader$slurp_edn_map.invokeStatic(reader.clj:38)
	at clojure.tools.deps.alpha.reader$slurp_edn_map.invoke(reader.clj:35)
	at clojure.tools.deps.alpha.reader$slurp_deps.invokeStatic(reader.clj:58)
	at clojure.tools.deps.alpha.reader$slurp_deps.invoke(reader.clj:54)
	at clojure.core$map$fn__5587.invoke(core.clj:2745)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.Cons.next(Cons.java:39)
	at clojure.lang.RT.boundedLength(RT.java:1785)
	at clojure.lang.RestFn.applyTo(RestFn.java:130)
	at clojure.core$apply.invokeStatic(core.clj:659)
	at clojure.core$apply.invoke(core.clj:652)
	at clojure.tools.deps.alpha.reader$merge_deps.invokeStatic(reader.clj:73)
	at clojure.tools.deps.alpha.reader$merge_deps.invoke(reader.clj:70)
	at clojure.tools.deps.alpha.reader$read_deps.invokeStatic(reader.clj:78)
	at clojure.tools.deps.alpha.reader$read_deps.invoke(reader.clj:75)
	at clojure.tools.deps.alpha.script.make_classpath$combine_deps_files.invokeStatic(make_classpath.clj:47)
	at clojure.tools.deps.alpha.script.make_classpath$combine_deps_files.invoke(make_classpath.clj:43)
	at clojure.tools.deps.alpha.script.make_classpath$run.invokeStatic(make_classpath.clj:68)
	at clojure.tools.deps.alpha.script.make_classpath$run.invoke(make_classpath.clj:64)
	at clojure.tools.deps.alpha.script.make_classpath$_main.invokeStatic(make_classpath.clj:109)
	at clojure.tools.deps.alpha.script.make_classpath$_main.doInvoke(make_classpath.clj:84)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.main$main_opt.invokeStatic(main.clj:317)
	at clojure.main$main_opt.invoke(main.clj:313)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)

Perhaps this involves an upstream enhancement in tools.deps.alpha, or alternatively, lein-tools-deps can run clojure -Sdescribe itself and show :err?

Heroku does not accept lein-tools-deps

The reason is that lein-tools-deps looks for the clojure cli command instead of executing the binaries retrieved by lein.

I have created a minimal project that reproduces this at https://github.com/AlexAti/lein-with-deps-project , which gives the following stacktrace when trying to deploy to Heroku:

       java.io.IOException: Cannot run program "clojure" (in directory "/tmp/build_54f7a078803f22e06807db4f6e663fb4"): error=2, No such file or directory
        at java.lang.ProcessBuilder.start (ProcessBuilder.java:1048)
           java.lang.Runtime.exec (Runtime.java:620)
           clojure.java.shell$sh.invokeStatic (shell.clj:113)
           clojure.java.shell$sh.doInvoke (shell.clj:79)
           clojure.lang.RestFn.invoke (RestFn.java:421)
           lein_tools_deps.env$scrape_clojure_env.invokeStatic (env.clj:32)
           lein_tools_deps.env$scrape_clojure_env.invoke (env.clj:27)
           clojure.lang.AFn.applyToHelper (AFn.java:154)
           clojure.lang.AFn.applyTo (AFn.java:144)

I'm trying in parallel to create a more robust buildpack for clojure at https://github.com/AlexAti/heroku-buildpack-clojure (still not working), but I think that, as leiningen is pulling already a version of clojure, lein-tools-deps should perhaps by default point to those binaries, instead of expecting that clojure is not only brought by leiningen but also locally installed, shouldn't it? This was also discussed on #62, #74 and #75 , but with the premise that clojure is installed somewhere, not brought by leiningen.

Does that make sense? I'm happy to help but I'd need some pointers :)

NPE when running lein

I am receiving this exception when running lein in a project that is using lein-tools-deps.

If there are a lot of uncached dependencies this might take a while ...
java.lang.NullPointerException: null
 at clojure.tools.deps.alpha.util.maven$make_session.invokeStatic (maven.clj:141)
    clojure.tools.deps.alpha.util.maven$make_session.invoke (maven.clj:138)
    clojure.tools.deps.alpha.extensions.maven$eval1000$fn__1002.invoke (maven.clj:76)
    clojure.lang.MultiFn.invoke (MultiFn.java:243)
    clojure.tools.deps.alpha$expand_deps.invokeStatic (alpha.clj:170)
    clojure.tools.deps.alpha$expand_deps.invoke (alpha.clj:152)
    clojure.tools.deps.alpha$resolve_deps.invokeStatic (alpha.clj:215)
    clojure.tools.deps.alpha$resolve_deps.invoke (alpha.clj:197)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.core$memoize$fn__5708.doInvoke (core.clj:6107)
    clojure.lang.RestFn.invoke (RestFn.java:421)
    lein_tools_deps.lein_project$resolve_deps.invokeStatic (lein_project.clj:54)
    lein_tools_deps.lein_project$resolve_deps.invoke (lein_project.clj:50)
    lein_tools_deps.plugin$apply_middleware.invokeStatic (plugin.clj:22)
    lein_tools_deps.plugin$apply_middleware.invoke (plugin.clj:17)
    lein_tools_deps.plugin$apply_middleware.invokeStatic (plugin.clj:25)
    lein_tools_deps.plugin$apply_middleware.invoke (plugin.clj:17)
    lein_tools_deps.plugin$resolve_dependencies_with_deps_edn.invokeStatic (plugin.clj:47)
    lein_tools_deps.plugin$resolve_dependencies_with_deps_edn.invoke (plugin.clj:34)
    clojure.lang.Var.invoke (Var.java:379)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:750)
    leiningen.core.project$apply_middleware.invoke (project.clj:743)
    clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)
    clojure.core.protocols$fn__6750.invokeStatic (protocols.clj:136)
    clojure.core.protocols/fn (protocols.clj:124)
    clojure.core.protocols$fn__6710$G__6705__6719.invoke (protocols.clj:19)
    clojure.core.protocols$seq_reduce.invokeStatic (protocols.clj:31)
    clojure.core.protocols$fn__6738.invokeStatic (protocols.clj:75)
    clojure.core.protocols/fn (protocols.clj:75)
    clojure.core.protocols$fn__6684$G__6679__6697.invoke (protocols.clj:13)
    clojure.core$reduce.invokeStatic (core.clj:6545)
    clojure.core$reduce.invoke (core.clj:6527)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:745)
    leiningen.core.project$apply_middleware.invoke (project.clj:743)
    leiningen.core.project$activate_middleware.invokeStatic (project.clj:777)
    leiningen.core.project$activate_middleware.invoke (project.clj:773)
    leiningen.core.project$init_project.invokeStatic (project.clj:902)
    leiningen.core.project$init_project.invoke (project.clj:892)
    leiningen.core.project$read.invokeStatic (project.clj:973)
    leiningen.core.project$read.invoke (project.clj:970)
    leiningen.core.project$read.invokeStatic (project.clj:974)
    leiningen.core.project$read.invoke (project.clj:970)
    leiningen.core.main$_main$fn__5998.invoke (main.clj:397)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:397)
    clojure.lang.Var.invoke (Var.java:375)
    clojure.lang.AFn.applyToHelper (AFn.java:152)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    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.main.main (main.java:37)

My project.clj looks like this:

(defproject http-backend "0.1.0"
  :plugins [[lein-tools-deps "0.4.1"]]
  :middleware [lein-tools-deps.plugin/resolve-dependencies-with-deps-edn]
  :lein-tools-deps/config {:config-files [:install :user :project]})

example fails to run

check out the project, cd into example, upgrade :plugins [[lein-tools-deps "0.4.2-SNAPSHOT"]] to :plugins [[lein-tools-deps "0.4.3"]] as 0.4.2-SNAPSHOT is not found in clojars.

as per readme do lein repl.

I get

$ lein repl
If there are a lot of uncached dependencies this might take a while ...
java.lang.NullPointerException: null
 at clojure.tools.deps.alpha.util.maven$make_session.invokeStatic (maven.clj:141)
    clojure.tools.deps.alpha.util.maven$make_session.invoke (maven.clj:138)
    clojure.tools.deps.alpha.extensions.maven$eval1004$fn__1006.invoke (maven.clj:78)
    clojure.lang.MultiFn.invoke (MultiFn.java:243)
    clojure.tools.deps.alpha$expand_deps.invokeStatic (alpha.clj:187)
    clojure.tools.deps.alpha$expand_deps.invoke (alpha.clj:168)
    clojure.tools.deps.alpha$resolve_deps.invokeStatic (alpha.clj:234)
    clojure.tools.deps.alpha$resolve_deps.invoke (alpha.clj:216)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.core$memoize$fn__5708.doInvoke (core.clj:6107)
    clojure.lang.RestFn.invoke (RestFn.java:421)
    lein_tools_deps.lein_project$resolve_deps.invokeStatic (lein_project.clj:54)
    lein_tools_deps.lein_project$resolve_deps.invoke (lein_project.clj:50)
    lein_tools_deps.plugin$apply_middleware.invokeStatic (plugin.clj:22)
    lein_tools_deps.plugin$apply_middleware.invoke (plugin.clj:17)
    lein_tools_deps.plugin$apply_middleware.invokeStatic (plugin.clj:25)
    lein_tools_deps.plugin$apply_middleware.invoke (plugin.clj:17)
    lein_tools_deps.plugin$resolve_dependencies_with_deps_edn.invokeStatic (plugin.clj:47)
    lein_tools_deps.plugin$resolve_dependencies_with_deps_edn.invoke (plugin.clj:34)
    clojure.lang.Var.invoke (Var.java:379)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:750)
    leiningen.core.project$apply_middleware.invoke (project.clj:743)
    clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)
    clojure.core.protocols$fn__6750.invokeStatic (protocols.clj:136)
    clojure.core.protocols/fn (protocols.clj:124)
    clojure.core.protocols$fn__6710$G__6705__6719.invoke (protocols.clj:19)
    clojure.core.protocols$seq_reduce.invokeStatic (protocols.clj:31)
    clojure.core.protocols$fn__6738.invokeStatic (protocols.clj:75)
    clojure.core.protocols/fn (protocols.clj:75)
    clojure.core.protocols$fn__6684$G__6679__6697.invoke (protocols.clj:13)
    clojure.core$reduce.invokeStatic (core.clj:6545)
    clojure.core$reduce.invoke (core.clj:6527)
    leiningen.core.project$apply_middleware.invokeStatic (project.clj:745)
    leiningen.core.project$apply_middleware.invoke (project.clj:743)
    leiningen.core.project$activate_middleware.invokeStatic (project.clj:777)
    leiningen.core.project$activate_middleware.invoke (project.clj:773)
    leiningen.core.project$init_project.invokeStatic (project.clj:902)
    leiningen.core.project$init_project.invoke (project.clj:892)
    leiningen.core.project$read.invokeStatic (project.clj:973)
    leiningen.core.project$read.invoke (project.clj:970)
    leiningen.core.project$read.invokeStatic (project.clj:974)
    leiningen.core.project$read.invoke (project.clj:970)
    leiningen.core.main$_main$fn__5998.invoke (main.clj:397)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.lang.Var.invoke (Var.java:379)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:436)
    clojure.lang.Var.invoke (Var.java:388)
    clojure.lang.AFn.applyToHelper (AFn.java:160)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

osx
clojure version

$ brew info clojure
clojure: stable 1.10.0.411

Affect lein deps :tree

It would be nice if lein deps :tree were updated to show some of the stuff that you can get from clojure -Stree, in particular if you have a git dep, the former won't show it, but the latter will.

Special profiles like :provided don't set scope properly on dependencies included via lein-tools-deps

e.g. a project.clj like this:

(defproject test-profile "0.1.0-SNAPSHOT"
  ,,,
  :plugins [[lein-tools-deps "0.4.3"]]

  :middleware [lein-tools-deps.plugin/resolve-dependencies-with-deps-edn]

  :lein-tools-deps/config {:aliases [:rebl]
                                         :config-files [:install :user :project]}

  :profiles {:provided {:lein-tools-deps/config {:aliases [:foo]}
                                  ;; :dependencies [[org.clojure/core.async "0.4.490"]]
                 }
  )

Should when running lein install`lein pomcreate a pom.xml in the jar with the dependencies from the:fooalias scoped asprovided. e.g. if you were to uncomment the :dependencies` line you'll see that core.async is marked correctly as a provided in the pom.xml:

,,,
 <dependency>
      <groupId>org.clojure</groupId>
      <artifactId>core.async</artifactId>
      <version>0.4.490</version>
      <scope>provided</scope>
    </dependency>
,,,

Dependencies with a classifier resolved incorrectly

tools.deps used to use the :classifier key within the dependency map to specify the classifier e.g.

groupId/artifactId {:mvn/version "1.0.0" :classifier "prod"}

this has now changed to specifying the classifier in the artifact name i.e.

groupId/artifactId$classifier {:mvn/version "1.0.0"}

lein-project/leinize should be updated to reflect this change.

Can't run `lein repl` without explicit dependency on tools.nrepl

project.clj:

(defproject blah "0.1.0-SNAPSHOT"
  :plugins [[lein-tools-deps "0.3.0-SNAPSHOT"]]
  :tools/deps [:system :home :project])

deps.edn:

{:deps {}}
~/c/blah> lein repl
Warning: no nREPL dependency detected.
Be sure to include org.clojure/tools.nrepl in :dependencies of your profile.
Error loading clojure.tools.nrepl.server: Could not locate clojure/tools/nrepl/server__init.class or clojure/tools/nrepl/server.clj on classpath.
Error loading complete.core: Could not locate complete/core__init.class or complete/core.clj on classpath.
Exception in thread "main" java.lang.ClassNotFoundException: clojure.tools.nrepl.server, compiling:(/private/var/folders/25/z_59070d5135pdfd4y1c1td00000gn/T/form-init7534147402379510545.clj:1:1093)

Changing deps.edn to the following fixes it:

{:deps {org.clojure/tools.nrepl {:mvn/version "0.2.12"}}}

Make :middleware explicit not implicit

Implicit middlewares are deprecated, we should migrate to using an explicit one.

This should simply be a matter of renaming the middleware function to something like resolve-dependencies-with-deps-edn and then updating the documentation and usage to require users to include the following config:

:lein-tools-deps/config {:config-files [:install :user :project]}
:plugins [[lein-tools-deps "0.4.0-SNAPSHOT"]]
:middleware [lein-tools-deps.plugin/resolve-dependencies-with-deps-edn]

:paths clobbers git deps paths

project.clj:

(defproject try-lein-tools-deps "0.1.0-SNAPSHOT"
  :plugins [[lein-tools-deps "0.2.0-SNAPSHOT"]]
  :tools/deps [:system :home :project])

deps.edn:

{#_#_:paths ["hello"]
 :deps {tubular {:git/url "https://github.com/mfikes/tubular" :sha "da17f3c82ee74ea183719e8c9f056575a2389ed0"}}}

lein classpath output:

/Users/mfikes/Desktop/try-lein-tools-deps/test:/Users/mfikes/.gitlibs/libs/tubular/tubular/da17f3c82ee74ea183719e8c9f056575a2389ed0/src:/Users/mfikes/Desktop/try-lein-tools-deps/dev-resources:/Users/mfikes/Desktop/try-lein-tools-deps/resources:/Users/mfikes/Desktop/try-lein-tools-deps/target/classes:/Users/mfikes/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar:/Users/mfikes/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar:/Users/mfikes/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar

In particular, the tubular git dep has a src suffix. If you uncoment the :paths key, you get

/Users/mfikes/Desktop/try-lein-tools-deps/test:/Users/mfikes/.gitlibs/libs/tubular/tubular/da17f3c82ee74ea183719e8c9f056575a2389ed0/hello:/Users/mfikes/Desktop/try-lein-tools-deps/dev-resources:/Users/mfikes/Desktop/try-lein-tools-deps/resources:/Users/mfikes/Desktop/try-lein-tools-deps/target/classes:/Users/mfikes/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar:/Users/mfikes/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar:/Users/mfikes/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar

(Notice that the src suffix on the git dep has now been replaced with hello.)

When #2 is addressed, hello should appear as a path in the output, but this ticket is about it interacting with the path formed for git deps.

Two local/root jars produces incorrect classpath

Try running lein repl with included files.
You should see sa-jdi.jar on the classpath but you will not:

issue.zip

chrisn@chrisn-dt:~/dev/tech.all/tech.jdi$ clj -R:test
Clojure 1.9.0
user=> (-> (ClassLoader/getSystemClassLoader)
(.getURLs)
(vec))
[#object[java.net.URL 0x4af0df05 "file:/home/chrisn/dev/tech.all/tech.jdi/src/"] 
 #object[java.net.URL 0x57ea113a "file:/home/chrisn/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar"]
 #object[java.net.URL 0xacdb094 "file:/home/chrisn/.m2/repository/camel-snake-kebab/camel-snake-kebab/0.4.0/camel-snake-kebab-0.4.0.jar"] 
 #object[java.net.URL 0x674bd420 "file:/home/chrisn/.m2/repository/techascent/tech.resource/4.0/tech.resource-4.0.jar"] 
 #object[java.net.URL 0x2b0f373b "file:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar"]  
 #object[java.net.URL 0x2ceb80a1 "file:/usr/lib/jvm/java-8-openjdk-amd64/lib/sa-jdi.jar"] 
 #object[java.net.URL 0x4b45dcb8 "file:/home/chrisn/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar"] 
 #object[java.net.URL 0x7216fb24 "file:/home/chrisn/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar"]]
chrisn@chrisn-dt:~/dev/tech.all/tech.jdi$ lein repl
If there are a lot of uncached dependencies this might take a while ...
nREPL server started on port 44227 on host 127.0.0.1 - nrepl://127.0.0.1:44227
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0
OpenJDK 64-Bit Server VM 1.8.0_191-8u191-b12-0ubuntu0.18.04.1-b12
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (-> (ClassLoader/getSystemClassLoader)
  #_=> (.getURLs)
  #_=> (vec))
[#object[java.net.URL 0x68f8a35e "file:/home/chrisn/dev/tech.all/tech.jdi/test"] 
 #object[java.net.URL 0x7925497 "file:/home/chrisn/dev/tech.all/tech.jdi/src/"] 
 #object[java.net.URL 0x69ea7a84 "file:/home/chrisn/dev/tech.all/tech.jdi/src/"] 
 #object[java.net.URL 0x189aa604 "file:/home/chrisn/dev/tech.all/tech.jdi/dev-resources"] 
 #object[java.net.URL 0x35d5141a "file:/home/chrisn/dev/tech.all/tech.jdi/resources"] 
 #object[java.net.URL 0x20f6d8db "file:/home/chrisn/dev/tech.all/tech.jdi/target/classes/"] 
 #object[java.net.URL 0x1a72a81b "file:/home/chrisn/.m2/repository/org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar"] 
 #object[java.net.URL 0x571587d7 "file:/home/chrisn/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar"] 
 #object[java.net.URL 0x4a7d2ceb "file:/home/chrisn/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar"] 
 #object[java.net.URL 0x5c5b057f "file:/home/chrisn/.m2/repository/camel-snake-kebab/camel-snake-kebab/0.4.0/camel-snake-kebab-0.4.0.jar"] 
 #object[java.net.URL 0x53e65c9f "file:/home/chrisn/.m2/repository/techascent/tech.resource/4.0/tech.resource-4.0.jar"] 
 #object[java.net.URL 0x28b6420b "file:/home/chrisn/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar"] 
 #object[java.net.URL 0xb8f2982 "file:/home/chrisn/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar"]]

Running this from emacs repl I get another answer

(->> (ClassLoader/getSystemClassLoader)
           (.getURLs)
           (mapv str))
["file:/home/chrisn/dev/tech.all/tech.jdi/test"
 "file:/home/chrisn/dev/tech.all/tech.jdi/src/"
 "file:/home/chrisn/dev/tech.all/tech.jdi/src/"
 "file:/home/chrisn/dev/tech.all/tech.jdi/dev-resources"
 "file:/home/chrisn/dev/tech.all/tech.jdi/resources"
 "file:/home/chrisn/dev/tech.all/tech.jdi/target/classes/"
 "file:/home/chrisn/.m2/repository/camel-snake-kebab/camel-snake-kebab/0.4.0/camel-snake-kebab-0.4.0.jar"
 "file:/home/chrisn/.m2/repository/techascent/tech.resource/4.0/tech.resource-4.0.jar"
 "file:/home/chrisn/.m2/repository/nrepl/nrepl/0.4.4/nrepl-0.4.4.jar"
 "file:/home/chrisn/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar"
 "file:/home/chrisn/.m2/repository/org/clojure/tools.nrepl/0.2.13/tools.nrepl-0.2.13.jar"
 "file:/home/chrisn/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar"
 "file:/home/chrisn/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar"
 "file:/home/chrisn/.m2/repository/org/clojure/tools.logging/0.4.1/tools.logging-0.4.1.jar"
 "file:/home/chrisn/.m2/repository/cider/cider-nrepl/0.18.0/cider-nrepl-0.18.0.jar"
 "file:/home/chrisn/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar"
 "file:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar"]

It seems like the /usr/lib path is getting thrown away because it has the same root or something like that.

I noticed that leinize multimethod does not support :jar manifest type. And the classpath pathway filters it out.

Doesn't work in leiningen 2.7.1

The simple fix is to use leiningen 2.8.1....

Almost certainly a dependency issue between leiningen/pomegranete/aether & tools.deps:

java.lang.NullPointerException: null
 at clojure.tools.deps.alpha.util.maven$make_session.invokeStatic (maven.clj:102)
    clojure.tools.deps.alpha.util.maven$make_session.invoke (maven.clj:99)
    clojure.tools.deps.alpha.providers.maven$eval2106$fn__2108.invoke (maven.clj:51)
    clojure.lang.MultiFn.invoke (MultiFn.java:243)
    clojure.tools.deps.alpha$expand_deps.invokeStatic (alpha.clj:36)
    clojure.tools.deps.alpha$expand_deps.invoke (alpha.clj:18)
    clojure.tools.deps.alpha$resolve_deps.invokeStatic (alpha.clj:99)
    clojure.tools.deps.alpha$resolve_deps.invoke (alpha.clj:89)
    leiningen.tools_deps$resolve_deps.invokeStatic (tools_deps.clj:22)
    leiningen.tools_deps$resolve_deps.invoke (tools_deps.clj:16)
    leiningen.tools_deps$eval2180.invokeStatic (NO_SOURCE_FILE:28)
    leiningen.tools_deps$eval2180.invoke (NO_SOURCE_FILE:28)
    clojure.lang.Compiler.eval (Compiler.java:6927)
    clojure.lang.Compiler.eval (Compiler.java:6890)
    clojure.core$eval.invokeStatic (core.clj:3105)
    clojure.core$eval.invoke (core.clj:3101)
    clojure.main$repl$read_eval_print__7408$fn__7411.invoke (main.clj:240)
    clojure.main$repl$read_eval_print__7408.invoke (main.clj:240)
    clojure.main$repl$fn__7417.invoke (main.clj:258)
    clojure.main$repl.invokeStatic (main.clj:258)
    clojure.main$repl.doInvoke (main.clj:174)
    clojure.lang.RestFn.invoke (RestFn.java:1523)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__10553.invoke (interruptible_eval.clj:87)
    clojure.lang.AFn.applyToHelper (AFn.java:152)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.core$with_bindings_STAR_.invokeStatic (core.clj:1881)
    clojure.core$with_bindings_STAR_.doInvoke (core.clj:1881)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic (interruptible_eval.clj:85)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:55)
    clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__10598$fn__10601.invoke (interruptible_eval.clj:222)
    clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__10593.invoke (interruptible_eval.clj:190)
    clojure.lang.AFn.run (AFn.java:22)
    java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142)
    java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
    java.lang.Thread.run (Thread.java:745)

I tried to use mranderson but couldn't get it to work, help appreciated.

Cannot exclude transitive dependencies two layers deep

I created a reproducible example repo, that has some more info in the README.

With a deps.edn that has exclusions for transitive dependency exclusions as below (ie clojurescript is not a direct dependency of uap-clj, but is a dependency of a dependency)

{:paths []
 :deps  {clj-http {:mvn/version "3.9.1" :exclusions [clj-tuple/clj-tuple ;; Transitive dependencies through potemkin
                                                     riddley/riddley]}
         uap-clj  {:mvn/version "1.3.3" :exclusions [com.taoensso/timbre ;; Transtive dependencies through russellwhitaker/immuconf
                                                     org.clojure/clojurescript]}}}

Running clj -Stree in the repo does not contain the excluded libraries, but lein deps :tree with lein-tools-deps set up does.

In my exploration of this issue I've found that the excluded transitive dependencies aren't present at the end of lein-tools-deps.plugin/resolve-dependencies-with-deps-edn, which seems to be correct behavior, but then they must get added sometime later by Leiningen internals.

Cannot find tools.deps.alpha

I get the following exception when running lein deps on the example project:

$ lein deps
Retrieving lein-tools-deps/lein-tools-deps/0.1.0-SNAPSHOT/lein-tools-deps-0.1.0-20171214.014635-1.pom from clojars
Retrieving lein-tools-deps/lein-tools-deps/0.1.0-SNAPSHOT/lein-tools-deps-0.1.0-20171214.014635-1.jar from clojars
Could not find artifact org.clojure:tools.deps.alpha:jar:0.2.197-SNAPSHOT in clojars (https://repo.clojars.org/)

I tried updating the tools.deps.alpha to the latest version (0.3.260), which doesn't work, probably because the interface has changed.

Updating to a previous version, tools.deps.alpha-0.2.196, seems to fix it.

Cannot use 0.4.3 - error due to missing dependency?

When bumping lein-tools-deps in my lein project.clj, I get the following error:

Exception in thread "Thread-2" clojure.lang.ExceptionInfo: Could not resolve dependencies {:suppress-msg true, :exit-code 1}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at clojure.core$ex_info.invoke(core.clj:4617)
	at leiningen.core.classpath$get_dependencies_STAR_.invokeStatic(classpath.clj:311)
	at leiningen.core.classpath$get_dependencies_STAR_.invoke(classpath.clj:265)
	at clojure.lang.AFn.applyToHelper(AFn.java:165)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:646)
	at clojure.core$memoize$fn__5708.doInvoke(core.clj:6107)
	at clojure.lang.RestFn.invoke(RestFn.java:457)
	at leiningen.core.classpath$get_dependencies$fn__3861.invoke(classpath.clj:332)
	at leiningen.core.classpath$get_dependencies.invokeStatic(classpath.clj:330)
	at leiningen.core.classpath$get_dependencies.doInvoke(classpath.clj:324)
	at clojure.lang.RestFn.invoke(RestFn.java:445)
	at clojure.lang.AFn.applyToHelper(AFn.java:160)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at clojure.core$apply.invokeStatic(core.clj:652)
	at clojure.core$apply.invoke(core.clj:641)
	at leiningen.core.classpath$resolve_managed_dependencies.invokeStatic(classpath.clj:443)
	at leiningen.core.classpath$resolve_managed_dependencies.doInvoke(classpath.clj:430)
	at clojure.lang.RestFn.invoke(RestFn.java:445)
	at leiningen.core.eval$prep.invokeStatic(eval.clj:85)
	at leiningen.core.eval$prep.invoke(eval.clj:73)
	at leiningen.core.eval$eval_in_project.invokeStatic(eval.clj:363)
	at leiningen.core.eval$eval_in_project.invoke(eval.clj:357)
	at leiningen.repl$server$fn__5963.invoke(repl.clj:278)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:646)
	at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1881)
	at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1881)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at clojure.core$apply.invokeStatic(core.clj:650)
	at clojure.core$bound_fn_STAR_$fn__4671.doInvoke(core.clj:1911)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.lang.Thread.run(Thread.java:748)
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Could not find artifact org.clojure:core.typed$slim:jar:0.5.3 in central (https://repo1.maven.org/maven2/)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:355)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at cemerick.pomegranate.aether$resolve_dependencies_STAR_.invokeStatic(aether.clj:806)
	at cemerick.pomegranate.aether$resolve_dependencies_STAR_.doInvoke(aether.clj:707)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:646)
	at clojure.core$apply.invoke(core.clj:641)
	at cemerick.pomegranate.aether$resolve_dependencies.invokeStatic(aether.clj:815)
	at cemerick.pomegranate.aether$resolve_dependencies.doInvoke(aether.clj:809)
	at clojure.lang.RestFn.invoke(RestFn.java:2793)
	at leiningen.core.classpath$get_dependencies_STAR_.invokeStatic(classpath.clj:273)
	... 35 more
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.clojure:core.typed$slim:jar:0.5.3 in central (https://repo1.maven.org/maven2/)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:422)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
	... 50 more
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.clojure:core.typed$slim:jar:0.5.3 in central (https://repo1.maven.org/maven2/)
	at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:48)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:364)
	at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:590)
	at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:258)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:498)
	at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:399)
	... 52 more

configuring lein-tools-deps as a plugin breaks the lein-zprint plugin

I am the maintainer of lein-zprint, and it turns out that if you have lein-tools-deps and lein-zprint both as plugins to Leiningen 2.8.1, lein-zprint doesn't work. This issue describes the problem, and this repo demonstrates the problem.

Nearly as I can tell, because lein-tools-deps is built with Clojure 1.9, it is causing the lein-zprint (and the underlying zprint library) to fail because lein-zprint is built with clojure-future-spec, which kind of "gets out of the way" of Clojure 1.9. At least when I clone and build lein-tools-deps with Clojure 1.8, lein-zprint works fine, and when I build lein-tools-deps with Clojure 1.9 as a :provided dependency, lein-zprint works fine. I have no idea if either of these things broke lein-tools-deps because I don't really know how to use it myself.

The root of all of this is that Leiningen doesn't yet support Clojure 1.9 plugins -- as this issue notes. I'm not expecting that to change anytime real soon. If it were possible for lein-tools-deps to be built with Clojure 1.8 that would certainly solve the problem. I think that when running as a Leiningen plugin it is running with Clojure 1.8 anyway, so that there is little loss in showing that as a dependency. But I could be wrong, I'm not super experienced in Leiningen plugins.

Anything help you could provide would be appreciated!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.