seancorfield / boot-tools-deps Goto Github PK

View Code? Open in Web Editor NEW

39.0 39.0 7.0 66 KB

A Boot task (deps) that wraps tools.deps(.alpha) to read deps.edn files

License: Eclipse Public License 1.0

Clojure 100.00%

boot-tools-deps's People

Contributors

Stargazers

Watchers

Forkers

grzm kennyjwilli superstructor theronic cbowdon nha clojure-land

boot-tools-deps's Issues

`-r` option should also ignore "system" `deps.edn` file

Alex just confirmed on Slack that tools.deps -Srepro option uses only the local deps.edn, not the system or user versions. Need to check what boot-tools-deps does (and fix that if not the same behavior).

Libraries that depend on older versions of Clojure

Hi @seancorfield. This is great, thanks

How do I deal with libraries that depend on e.g. Clojure 1.7 when the boot pod is running in Clojure 1.9? Would it be possible to recursively build each Git checkout lib using a separate boot process, to produce artifacts for linking?

deps task throws exception in most/many situations

Given this project https://github.com/drewverlee/example-1

Run boot -h

I get an unexpected exception, of which this seems to be the relevent part:

java.lang.ClassCastException: java.lang.Character cannot be cast to java.util.Map$Entry.

Appears to ignore :exclusions in deps.edn coords

If I add an :exclusions keyval in a dep coordinate boot-tools-deps appears to ignore it.

Consider wrapping `load-deps` function call in with-pre-wrap

This probably isn't a very common scenario but maybe still worth considering

(deftask my-deps []
  (comp (with-pass-thru _
          (println "first task"))
        (deps)))

With the current task load-deps will be called at the time the task pipeline is constructed rather than when the task is actually being ran. The following would preserve the task order:

  (boot/with-pass-thru _
    (load-deps {:config-paths      config-paths
                :classpath-aliases classpath-aliases
                :resolve-aliases   resolve-aliases
                :repeatable        repeatable
                :verbose           verbose})))

Add -Q (or similar) to merge :dependencies

Since -B completely overwrites Boot's :dependencies vector, some Boot tooling (e.g., boot-alt-test) won't work at all, and even other tooling (e.g., boot-test) may build pods based on :dependencies rather than depending on the classpath (which is correct).

Add a "merge" option with a funky name so folks are clear that it does something strange (see our old friend issue #7 for example).

Issue with private repos and transitive dependencies

I'm having an issue with transitive dependencies in a corporate repo. When I refer to my company dependencies that have transitive dependencies within the corporate repo (setting the repo in :mvn/repos within deps.edn), the 'deps' task seems to be trying to locate the transitive dependencies in clojars first.

Here's what happens when I do either

(boot (deps :overwrite-boot-deps true))

(boot (deps :quick-merge true))

error:

org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact com.xxx-masked-group:xxx-masked-artifact:jar:1.0.1 in clojars (https://repo.clojars.org/)

I initially thought this was an issue with tools-deps, but I can run a repl with the 'clj' tool without a problem (clj tool builds a clean dependency tree and classpath).

Is this expected (a function of using the boot dependency resolution)? It's funny because if I add those dependencies to the build.boot file rather than deps.edn, they are cleanly resolved.

Refactor tools-deps to match load-deps

Move setup code from load-deps to tools-deps so arguments match. Document use as a library.

Put tools.deps in a pod?

Not sure if this is worth it or even possible but could we put the tools.deps machinery into a pod?

Leaving this here for later consideration.

:scope doesn't affect transitive deps

I noticed that if I make a dependency :scope "test", all of its transitive deps are still included in any jar file that I build. After looking at the code, I believe this is because you are using tools.deps to resolve the dependencies before passing them to Boot. Any reason why you don't just let Boot do the resolving?

Expand/clarify readme to explain how boot-tools-deps is expected to be used

From my comments on Slack:

It appears I need to do a better job at communicating how boot-tools-deps is intended to be used 😄 I'll have a think about that and try expand the readme today.

The TL;DR is that it expects you to have a project setup with deps.edn where you can already start a REPL or run code via clj. It expects you to use aliases to keep your build / dev / test dependencies separate.

Could not locate boot_tools_deps/pod__init.class or boot_tools_deps/pod.clj on classpath

I added [seancorfield/boot-tools-deps "0.4.0"] as a dependency to an older project and I'm getting this error, which I expect is version related. Running boot 2.7.2 with Clojure 1.8. Also tried 1.9.


                                       java.lang.Thread.run                  Thread.java:  748
         java.util.concurrent.ThreadPoolExecutor$Worker.run      ThreadPoolExecutor.java:  624
          java.util.concurrent.ThreadPoolExecutor.runWorker      ThreadPoolExecutor.java: 1149
                        java.util.concurrent.FutureTask.run              FutureTask.java:  266
                                                        ...                                   
                        clojure.core/binding-conveyor-fn/fn                     core.clj: 1938
                                          boot.core/boot/fn                     core.clj: 1032
                                                        ...                                   
                                  boot.core/construct-tasks                     core.clj:  994
                                         clojure.core/apply                     core.clj:  646
                                                        ...                                   
                       boot.user$eval2406$fn__2407.doInvoke                             :   64
                                                        ...                                   
                       boot.user$eval2376$fn__2377.doInvoke                             :   45
                                                        ...                                   
              boot.user$eval2343$fn__2344$fn__2345.doInvoke                             :   37
                                         clojure.core/apply                     core.clj:  646
                                                        ...                                   
                             boot-tools-deps.core/eval81/fn                     core.clj:  203
                             boot-tools-deps.core/load-deps                     core.clj:  117
                            boot-tools-deps.core/tools-deps                     core.clj:  101
                                          boot.pod/call-in*                      pod.clj:  413
                                                        ...                                   
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke  ClojureRuntimeShimImpl.java:  102
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke  ClojureRuntimeShimImpl.java:  109
                                                        ...                                   
                                          boot.pod/call-in*                      pod.clj:  410
                                      boot.pod/eval-fn-call                      pod.clj:  357
                                                        ...                                   
                                       clojure.core/require                     core.clj: 5947 (repeats 2 times)
                                         clojure.core/apply                     core.clj:  659
                                                        ...                                   
                                     clojure.core/load-libs                     core.clj: 5909
                                     clojure.core/load-libs                     core.clj: 5925
                                         clojure.core/apply                     core.clj:  659
                                                        ...                                   
                                      clojure.core/load-lib                     core.clj: 5868
                                      clojure.core/load-lib                     core.clj: 5887
                                   clojure.core/load-lib/fn                     core.clj: 5888
                                      clojure.core/load-one                     core.clj: 5848
                                                        ...                                   
                                          clojure.core/load                     core.clj: 6029
                                          clojure.core/load                     core.clj: 6045
                                       clojure.core/load/fn                     core.clj: 6046
                                                        ...                                   
java.io.FileNotFoundException: Could not locate boot_tools_deps/pod__init.class or boot_tools_deps/pod.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
   clojure.lang.ExceptionInfo: Could not locate boot_tools_deps/pod__init.class or boot_tools_deps/pod.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
    line: 77

boot.properties looks like this:

#http://boot-clj.com
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.2
BOOT_EMIT_TARGET=no

Version ranges for org.clojure/clojure when not using ranges

I'm looking into using a deps.edn file with boot-tools-deps to manage subprojects in a monorepo at work. I've stumbled at this hurdle:

                  boot-tools-deps.pod/build-environment-map                      pod.clj:   43
                      clojure.tools.deps.alpha/resolve-deps                    alpha.clj:  215
                       clojure.tools.deps.alpha/expand-deps                    alpha.clj:  170
                 clojure.tools.deps.alpha/canonicalize-deps                    alpha.clj:   60
                                        clojure.core/reduce                     core.clj: 6747
                                                        ...                                   
              clojure.tools.deps.alpha/canonicalize-deps/fn                    alpha.clj:   61
                                                        ...                                   
       clojure.tools.deps.alpha.extensions.maven/eval352/fn                    maven.clj:   37
                                       clojure.core/ex-info                     core.clj: 4739
clojure.lang.ExceptionInfo: In the dependency graph, library org.clojure/clojure specifies version range "[1.2,1.6)" - please specify a version in your configuration.
    data: {#object[clojure.lang.Keyword 0x41b857de ":lib"] #object[clojure.lang.Symbol 0x4d74c3ba "org.clojure/clojure"], #object[clojure.lang.Keyword 0x674bcb13 ":coord"] {#object[clojure.lang.Keyword 0x3fb4d36a ":mvn/version"] "[1.2,1.6)"}}
clojure.lang.ExceptionInfo: In the dependency graph, library org.clojure/clojure specifies version range "[1.2,1.6)" - please specify a version in your configuration.

Interestingly, I'm not using version ranges. 🙂

If I run clj in the directory with the deps.edn file I get a REPL pop up, which makes me think this might be a boot-tools-deps issue.

I'm using the following invocation of deps:

(deps :config-paths #{"web/deps.edn"}
      :verbose 2
      :repeatable true
      :aliases #{:dev :test})

All the output regarding Clojure looks like this:

Expanding org.clojure/clojure {:mvn/version 1.4.0}
    => skip, top dep used instead

I've tried adding an override to the web/deps.edn but that hasn't helped.

 :override-deps
 {org.clojure/clojure {:mvn/version "1.9.0"}}

Link to the conversation I've started in Clojurians: https://clojurians.slack.com/archives/C6QH853H8/p1518699842000326.

How to use different classpath for each task in a pipeline

Hi,

This might be impossible or wrong thinking on my part - I'm certainly not sure that it's a bug.
I have a program I'm building with boot that has a frontend in clojurescript and backend in clojure.

To build it I need to do clojurescript compilation for the frontend bits, and AOT + uberjar stuff for the backend bits.

The frontend build has different dependencies to the backend build, which are split by aliases in deps.edn.

What I have tried to do is write something like this

(deftask build-frontend []
   (comp (deps :aliases [:client]) (cljs)))

(deftask build-jar []
   (comp (build-frontend) (deps :aliases [:server] :overwrite-boot-deps true) (aot) (pom) (uber) (jar)))

However, as far as I can tell the effect of (deps) is not within task execution but in the construction of the task pipeline. What happens if I stick in a bunch of printlns and verbosity is:

(deps :aliases [:client]) modifies the classpath to contain the client-side dependencies
(deps :aliases [:server] :overwrite-boot-deps true) zaps the classpath, throwing all that away
The other tasks get run; (cljs) fails because it can't resolve dependencies from the :client alias (the reason cljs exists at all is because I actually resolve its definition in the deftask before anything else happens, for other reasons)

Do you know if there is some voodoo I can do here to be able to say: make a pipeline of these tasks; run the first task with these dependencies and the second with these other dependencies.

Thank you for your work,

Tom

How to handle local and git deps?

tools.deps(.alpha) supports both local and git dependencies -- how should these work with boot-tools-deps?

Should the defaults include :paths / :extra-paths?

Given that the default behavior of clj is to pick up your src folder and, with -R:test, to pick up your test folder, and these can easily be overridden in your local deps.edn, should boot-tools-deps also provide these defaults?

Is there a way to automate the defaults based on whatever the clj installer lays down?

How to require git deps for libs that are used in build.boot?

I need to use a fork of boot-react-native. I've added a :local/root path in deps.edn.

I see there is a :quick-merge argument. I tried to use it, but I don't know how.

How should I "bootstrap" dependencies that are required in the build.boot file which do not originate from Maven?

Transitive deps are added to the pom

It seems like my generated pom.xml has not only the dependencies I specified in deps.edn, but all their transitive dependencies as well. While technically this shouldn't matter, I'd prefer my poms nice and clean.

To reproduce:

add org.clojure/clojurescript {:mvn/version "1.9.946"} to your deps.edn
boot deps --overwrite-boot-deps pom target
check out the generated pom.xml; it should have extra transitive dependencies listed such as google-closure-library

Track brew-install/tools.deps.alpha releases (Clojars repo URL change)

The default Clojars repo URL has been updated in both repos but not yet released in new versions. Our next build/deploy will pick that up but I'd rather wait until the upstream libs release again.

seancorfield / boot-tools-deps Goto Github PK

boot-tools-deps's People

Contributors

Stargazers

Watchers

Forkers

boot-tools-deps's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs