benedekfazekas / mranderson Goto Github PK
View Code? Open in Web Editor NEWDependency inlining and shadowing
License: Eclipse Public License 1.0
Dependency inlining and shadowing
License: Eclipse Public License 1.0
I ran into the following problem when trying to release cider-nrepl 0.25.6:
lein with-profile +1.10,+plugin.mranderson/config deploy clojars
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Compiling cider.nrepl.inlined-deps.cljfmt.v0v7v0.cljfmt.main
Syntax error macroexpanding at (diff.clj:1:1).
Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:435).
cidernrepl0256.difflib.DiffUtils
It doesn't seem to be a regression in the most recent mranderson, as I got the same problem with the previous release as well. I've reverted to cljfmt 0.6.8, so I can release something but ideally we should fix this problem somehow.
You can easily reproduce this by running on the current master of cider-nrepl. I'm using JDK 14, but I'm not sure if that's relevant or the problem's there for every JDK.
clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Too many arguments to throw, throw expects a single Throwable instance, compiling:(mranderson/move.clj:106:5)
at clojure.lang.Compiler.analyzeSeq (Compiler.java:6875)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2805)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6319)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
clojure.lang.Compiler$FnMethod.parse (Compiler.java:5380)
clojure.lang.Compiler$FnExpr.parse (Compiler.java:3972)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6866)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.access$300 (Compiler.java:38)
clojure.lang.Compiler$DefExpr$Parser.parse (Compiler.java:589)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler.eval (Compiler.java:6931)
clojure.lang.Compiler.load (Compiler.java:7379)
clojure.lang.RT.loadResourceScript (RT.java:372)
clojure.lang.RT.loadResourceScript (RT.java:363)
clojure.lang.RT.load (RT.java:453)
clojure.lang.RT.load (RT.java:419)
clojure.core$load$fn__5677.invoke (core.clj:5893)
clojure.core$load.invokeStatic (core.clj:5892)
clojure.core$load.doInvoke (core.clj:5876)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$load_one.invokeStatic (core.clj:5697)
clojure.core$load_one.invoke (core.clj:5692)
clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
clojure.core$load_lib.invokeStatic (core.clj:5736)
clojure.core$load_lib.doInvoke (core.clj:5717)
clojure.lang.RestFn.applyTo (RestFn.java:142)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$load_libs.invokeStatic (core.clj:5774)
clojure.core$load_libs.doInvoke (core.clj:5758)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$require.invokeStatic (core.clj:5796)
clojure.core$require.doInvoke (core.clj:5796)
clojure.lang.RestFn.invoke (RestFn.java:805)
leiningen.source_deps$eval1023$loading__5569__auto____1024.invoke (source_deps.clj:1)
leiningen.source_deps$eval1023.invokeStatic (source_deps.clj:1)
leiningen.source_deps$eval1023.invoke (source_deps.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6927)
clojure.lang.Compiler.eval (Compiler.java:6916)
clojure.lang.Compiler.load (Compiler.java:7379)
clojure.lang.RT.loadResourceScript (RT.java:372)
clojure.lang.RT.loadResourceScript (RT.java:363)
clojure.lang.RT.load (RT.java:453)
clojure.lang.RT.load (RT.java:419)
clojure.core$load$fn__5677.invoke (core.clj:5893)
clojure.core$load.invokeStatic (core.clj:5892)
clojure.core$load.doInvoke (core.clj:5876)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$load_one.invokeStatic (core.clj:5697)
clojure.core$load_one.invoke (core.clj:5692)
clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
clojure.core$load_lib.invokeStatic (core.clj:5736)
clojure.core$load_lib.doInvoke (core.clj:5717)
clojure.lang.RestFn.applyTo (RestFn.java:142)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$load_libs.invokeStatic (core.clj:5774)
clojure.core$load_libs.doInvoke (core.clj:5758)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$require.invokeStatic (core.clj:5796)
clojure.core$require.doInvoke (core.clj:5796)
clojure.lang.RestFn.invoke (RestFn.java:408)
leiningen.core.utils$require_resolve.invokeStatic (utils.clj:89)
leiningen.core.utils$require_resolve.invoke (utils.clj:82)
leiningen.core.utils$require_resolve.invokeStatic (utils.clj:92)
leiningen.core.utils$require_resolve.invoke (utils.clj:82)
leiningen.core.main$lookup_task_var.invokeStatic (main.clj:68)
leiningen.core.main$lookup_task_var.invoke (main.clj:64)
leiningen.core.main$pass_through_help_QMARK_.invokeStatic (main.clj:78)
leiningen.core.main$pass_through_help_QMARK_.invoke (main.clj:72)
leiningen.core.main$task_args.invokeStatic (main.clj:81)
leiningen.core.main$task_args.invoke (main.clj:80)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:327)
leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
leiningen.do$do.invokeStatic (do.clj:40)
leiningen.do$do.doInvoke (do.clj:32)
clojure.lang.RestFn.invoke (RestFn.java:486)
clojure.lang.Var.invoke (Var.java:401)
clojure.lang.AFn.applyToHelper (AFn.java:171)
clojure.lang.Var.applyTo (Var.java:700)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$partial_task$fn__5837.doInvoke (main.clj:272)
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.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$apply_task.invokeStatic (main.clj:322)
leiningen.core.main$apply_task.invoke (main.clj:308)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
leiningen.core.main$_main$fn__5903.invoke (main.clj:401)
leiningen.core.main$_main.invokeStatic (main.clj:394)
leiningen.core.main$_main.doInvoke (main.clj:391)
clojure.lang.RestFn.invoke (RestFn.java:482)
clojure.lang.Var.invoke (Var.java:401)
clojure.lang.AFn.applyToHelper (AFn.java:171)
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:551)
clojure.lang.Var.invoke (Var.java:419)
clojure.lang.AFn.applyToHelper (AFn.java:186)
clojure.lang.Var.applyTo (Var.java:700)
clojure.main.main (main.java:37)
Caused by: java.lang.RuntimeException: Too many arguments to throw, throw expects a single Throwable instance
at clojure.lang.Util.runtimeException (Util.java:221)
clojure.lang.Compiler$ThrowExpr$Parser.parse (Compiler.java:2428)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2805)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6319)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
clojure.lang.Compiler$FnMethod.parse (Compiler.java:5380)
clojure.lang.Compiler$FnExpr.parse (Compiler.java:3972)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6866)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.access$300 (Compiler.java:38)
clojure.lang.Compiler$DefExpr$Parser.parse (Compiler.java:589)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
clojure.lang.Compiler.analyze (Compiler.java:6669)
clojure.lang.Compiler.analyze (Compiler.java:6625)
clojure.lang.Compiler.eval (Compiler.java:6931)
clojure.lang.Compiler.load (Compiler.java:7379)
clojure.lang.RT.loadResourceScript (RT.java:372)
clojure.lang.RT.loadResourceScript (RT.java:363)
clojure.lang.RT.load (RT.java:453)
clojure.lang.RT.load (RT.java:419)
clojure.core$load$fn__5677.invoke (core.clj:5893)
clojure.core$load.invokeStatic (core.clj:5892)
clojure.core$load.doInvoke (core.clj:5876)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$load_one.invokeStatic (core.clj:5697)
clojure.core$load_one.invoke (core.clj:5692)
clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
clojure.core$load_lib.invokeStatic (core.clj:5736)
clojure.core$load_lib.doInvoke (core.clj:5717)
clojure.lang.RestFn.applyTo (RestFn.java:142)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$load_libs.invokeStatic (core.clj:5774)
clojure.core$load_libs.doInvoke (core.clj:5758)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$require.invokeStatic (core.clj:5796)
clojure.core$require.doInvoke (core.clj:5796)
clojure.lang.RestFn.invoke (RestFn.java:805)
leiningen.source_deps$eval1023$loading__5569__auto____1024.invoke (source_deps.clj:1)
leiningen.source_deps$eval1023.invokeStatic (source_deps.clj:1)
leiningen.source_deps$eval1023.invoke (source_deps.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6927)
clojure.lang.Compiler.eval (Compiler.java:6916)
clojure.lang.Compiler.load (Compiler.java:7379)
clojure.lang.RT.loadResourceScript (RT.java:372)
clojure.lang.RT.loadResourceScript (RT.java:363)
clojure.lang.RT.load (RT.java:453)
clojure.lang.RT.load (RT.java:419)
clojure.core$load$fn__5677.invoke (core.clj:5893)
clojure.core$load.invokeStatic (core.clj:5892)
clojure.core$load.doInvoke (core.clj:5876)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$load_one.invokeStatic (core.clj:5697)
clojure.core$load_one.invoke (core.clj:5692)
clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
clojure.core$load_lib.invokeStatic (core.clj:5736)
clojure.core$load_lib.doInvoke (core.clj:5717)
clojure.lang.RestFn.applyTo (RestFn.java:142)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$load_libs.invokeStatic (core.clj:5774)
clojure.core$load_libs.doInvoke (core.clj:5758)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$require.invokeStatic (core.clj:5796)
clojure.core$require.doInvoke (core.clj:5796)
clojure.lang.RestFn.invoke (RestFn.java:408)
leiningen.core.utils$require_resolve.invokeStatic (utils.clj:89)
leiningen.core.utils$require_resolve.invoke (utils.clj:82)
leiningen.core.utils$require_resolve.invokeStatic (utils.clj:92)
leiningen.core.utils$require_resolve.invoke (utils.clj:82)
leiningen.core.main$lookup_task_var.invokeStatic (main.clj:68)
leiningen.core.main$lookup_task_var.invoke (main.clj:64)
leiningen.core.main$pass_through_help_QMARK_.invokeStatic (main.clj:78)
leiningen.core.main$pass_through_help_QMARK_.invoke (main.clj:72)
leiningen.core.main$task_args.invokeStatic (main.clj:81)
leiningen.core.main$task_args.invoke (main.clj:80)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:327)
leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
leiningen.do$do.invokeStatic (do.clj:40)
leiningen.do$do.doInvoke (do.clj:32)
clojure.lang.RestFn.invoke (RestFn.java:486)
clojure.lang.Var.invoke (Var.java:401)
clojure.lang.AFn.applyToHelper (AFn.java:171)
clojure.lang.Var.applyTo (Var.java:700)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$partial_task$fn__5837.doInvoke (main.clj:272)
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.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$apply_task.invokeStatic (main.clj:322)
leiningen.core.main$apply_task.invoke (main.clj:308)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
leiningen.core.main$_main$fn__5903.invoke (main.clj:401)
leiningen.core.main$_main.invokeStatic (main.clj:394)
leiningen.core.main$_main.doInvoke (main.clj:391)
clojure.lang.RestFn.invoke (RestFn.java:482)
clojure.lang.Var.invoke (Var.java:401)
clojure.lang.AFn.applyToHelper (AFn.java:171)
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:551)
clojure.lang.Var.invoke (Var.java:419)
clojure.lang.AFn.applyToHelper (AFn.java:186)
clojure.lang.Var.applyTo (Var.java:700)
clojure.main.main (main.java:37)
When starting lein repl
I get a number of warnings:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson049.orchard.v0v4v0.dynapath.v0v2v5.dynapath.defaults$eval3663$fn__3664 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson049.orchard.v0v4v0.dynapath.v0v2v5.dynapath.defaults$eval3663$fn__3664
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
My profiles.clj:
{:system {:jvm-opts ["-Duser.timezone=UTC"]}
:user {:plugins [[lein-ancient "0.6.15" :exclusions [org.clojure/clojure]]
[thomasa/mranderson "0.5.1"]
[cider/cider-nrepl "0.21.1"]
[lein-pprint "1.2.0"]
[jonase/eastwood "0.3.3"]
[lein-try "0.4.3"]]
:dependencies [[com.bhauman/rebel-readline "0.1.4"]]
:aliases {"rebl" ["trampoline" "run" "-m" "rebel-readline.main"]}
:injections []}}
Comparing Java 11 to Java 16, it seems on the latter MrAnderson is an order of maginitude slower than on the former.
Using sdkman
$ sdk use java 11.0.10.hs-adpt
$ /usr/bin/time lein test
73.42user 1.79system 0:28.42elapsed 264%CPU (0avgtext+0avgdata 926716maxresident)k
27088inputs+37504outputs (126major+262412minor)pagefaults 0swaps
$ sdk use java 16.0.1.hs-adpt
$ /usr/bin/time lein test
700.25user 1363.14system 5:06.12elapsed 674%CPU (0avgtext+0avgdata 393300maxresident)k
0inputs+18000outputs (157major+156929minor)pagefaults 0swaps
So 5 minutes instead of 28 seconds. A cider-nrepl build is taking half an hour on my machine.
Not sure if this is a red herring, but on the latter I'm getting this warning
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 an
d will likely be removed in a future release.
The MrAnderson readme has a cljdoc badge which is showing "API import failed":
I assume that we'd like to fix this.
Cljdoc is barfing when trying to load mranderson.util
namespace.
It references leiningen.core.main
which is not on the classpath during cljdoc analysis.
Cljdoc API docs ideally document the public API of a library.
I don't know what the public API of mranderson is, but once I do, we can tell cljdoc to ignore mranderson internals via :no-doc
metadata on mranderson namespaces and vars that are considered internal.
This might well be enough to fix cljdoc API analysis.
If not we can explore further.
My current guess a public supported nses:
mranderson.core
mrnaderson.plugin
I am happy to follow up with a PR once we agree on an approach.
so MrAnderson can be used by a third party, maybe from the REPL to pull in a dep and shadow it.
This is easy to reproduce with the lein-collisions plugin in a project depending on cider
and cljfmt
:
$ lein collisions
cljfmt/indents/clojure.clj -- 2 collisions:
-- /home/user/.m2/repository/cider/cider-nrepl/0.9.1/cider-nrepl-0.9.1.jar
-- /home/user/.m2/repository/cljfmt/cljfmt/0.2.0/cljfmt-0.2.0.jar
...
almost all leinigen
specific code is already in leiningen.inline-deps
, however mranderson.util
still references leiningen for logging. if this latter is eliminated leiningen could be excluded when mranderson is used directly
related to #35
example from here from claypoole
(:import
[com.climate.claypoole.impl
PriorityThreadpool
PriorityThreadpoolImpl]
[...])
this import prefixes two classes of claypoole itself. One of those classes is created with a deftype, the other one is created by a java class. MrAnderson prefixing deftype based classes in imports is a separate step from prefixing java class based classes in imports. The logic prefixing them is also different resulting in different prefixes. This means that inlining this library breaks now because the deftype prefixing "wins" for this import but this would render the java class based import wrong.
To fix either aline the two steps so they generate the same prefix or split this import into two so they can have different prefixes.
There's a RFC on this pull request on pomegranate. Will this affect mranderson?
As it is a touched up version of clojure.tools.namespace.move
could be used separately from MrAnderson
I have the following project.clj
(defproject positano "0.3.0-SNAPSHOT"
:description "Provenace system for Clojure"
:url "https://github.com/stathissideris/positano"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.8.0"]
^:source-dep [datascript "0.15.0"]
^:source-dep [org.clojure/core.async "0.2.385"]
^:source-dep [org.clojure/tools.analyzer.jvm "0.6.10"]]
:plugins [[thomasa/mranderson "0.4.7"]]
:profiles {:dev {:source-paths ["src" "dev"]
:dependencies [[org.clojure/tools.namespace "0.2.11"]]}})
Running the tests with mranderson, results in this exception:
โ positano lein with-profile +plugin.mranderson/config test
Exception in thread "main" java.lang.ClassNotFoundException: datascript.pull_parser.PullSpec, compiling:(mranderson047/datascript/v0v15v0/datascript/pull_api.cljc:1:1)
PullSpec
is a record defined in a different namespace of datascript:
https://github.com/tonsky/datascript/blob/master/src/datascript/pull_parser.cljc
You can try my project here:
Tools like https://cljdoc.org that generate API documentation will see inlined deps namespaces like any other namespace. This makes it hard to exclude namespaces from inlined dependencies from API documentation; making the API docs harder to read for end users.
It would be great of MrAnderson could attach some metadata to inlined namespaces so that those namespaces can be identified and excluded from API documentation. Perhaps just :no-doc
is fine but something more MrAnderson specific would also be reasonable and useful enough.
Here's an example of how this affects the cider-nrepl API docs.
Hey again ๐
clj-tuple (a transient dependency of clj-http
, in my case) has a top-level clj-tuple
namespace, which isn't getting included in :import
replacements. I reckon it's because clj-files->dirs
has a (remove str/blank?)
, but removing this leads to target/srcdeps
being included in clj-dirs
, and I wasn't satisfied that I understood all the impacts of this before naively removing it :)
James
provide options to define them in the project file or on CLI where the option is missing and makes sense
since those dependencies are prefixed by mranderson but the test files are processed at the moment.
see a particular case of this: clojure-emacs/cider-nrepl#183
sometimes files in dependencies come out broken (part of the file is missing therefore parens are not closed). gut feeling is that something goes wrong when files are processed in parallel.
example
fazekasbenedek@scatha:~/projects/cider-nrepl (master)$ make test
lein with-profile -user inline-deps
project prefix: cider.nrepl.inlined-deps
retrieve dependencies and munge clojure source files
in RESOLVED-TREE mode, working on a resolved dependency tree
[cljfmt "0.8.0" :exclusions [[org.clojure/clojure] [org.clojure/clojurescript]]]
[com.googlecode.java-diff-utils/diffutils "1.3.0"]
[org.clojure/tools.cli "1.0.206"]
[rewrite-clj "1.0.605-alpha"]
[org.clojure/tools.namespace "1.0.0" :exclusions [[org.clojure/clojure]]]
[org.clojure/java.classpath "1.0.0"]
[compliment "0.3.11" :exclusions [[org.clojure/clojure]]]
[org.clojure/tools.trace "0.7.10" :exclusions [[org.clojure/clojure]]]
[org.rksm/suitable "0.4.0" :exclusions [[org.clojure/clojure] [org.clojure/clojurescript]]]
[cider/orchard "0.7.1" :exclusions [[org.clojure/clojure]]]
[org.tcrawley/dynapath "1.1.0" :exclusions [[org.clojure/clojure]]]
[org.clojure/tools.reader "1.3.2" :exclusions [[org.clojure/clojure]]]
[fipp "0.6.24" :exclusions [[org.clojure/clojure]]]
[org.clojure/core.rrb-vector "0.1.1"]
[thunknyc/profile "0.5.2" :exclusions [[org.clojure/clojure]]]
[mvxcvi/puget "1.3.1" :exclusions [[org.clojure/clojure]]]
[mvxcvi/arrangement "1.2.0"]
unzipping [ orchard [ v0v7v1 ]]
unzipping [ profile [ v0v5v2 ]]
unzipping [ dynapath [ v1v1v0 ]]
unzipping [ toolsnamespace [ v1v0v0 ]]
unzipping [ cljfmt [ v0v8v0 ]]
unzipping [ rewrite-clj [ v1v0v605-alpha ]]
unzipping [ toolsreader [ v1v3v2 ]]
unzipping [ suitable [ v0v4v0 ]]
unzipping [ puget [ v1v3v1 ]]
unzipping [ fipp [ v0v6v24 ]]
unzipping [ corerrb-vector [ v0v1v1 ]]
unzipping [ javaclasspath [ v1v0v0 ]]
unzipping [ diffutils [ v1v3v0 ]]
unzipping [ arrangement [ v1v2v0 ]]
unzipping [ toolstrace [ v0v7v10 ]]
unzipping [ toolscli [ v1v0v206 ]]
unzipping [ compliment [ v0v3v11 ]]
munge source files of compliment artifact on branch [] exposed false.
munge source files of toolscli artifact on branch [] exposed false.
munge source files of toolstrace artifact on branch [] exposed false.
munge source files of arrangement artifact on branch [] exposed false.
munge source files of diffutils artifact on branch [] exposed false.
munge source files of javaclasspath artifact on branch [] exposed false.
munge source files of corerrb-vector artifact on branch [] exposed false.
munge source files of fipp artifact on branch [] exposed false.
munge source files of puget artifact on branch [] exposed false.
munge source files of suitable artifact on branch [] exposed false.
munge source files of toolsreader artifact on branch [] exposed false.
munge source files of rewrite-clj artifact on branch [] exposed false.
munge source files of cljfmt artifact on branch [] exposed false.
prefixing imports in clojure files in 'target/srcdeps/cljfmt' ...
prefixing imports: done
munge source files of toolsnamespace artifact on branch [] exposed false.
munge source files of dynapath artifact on branch [] exposed false.
munge source files of profile artifact on branch [] exposed false.
munge source files of orchard artifact on branch [] exposed false.
jaring all class file dependencies into target/class-deps.jar
prefixing #{"difflib"} in target/class-deps.jar with cidernrepl0270SNAPSHOT
deleting directories with class files in target/srcdeps...
difflib deleted
unzipping repackaged class-deps.jar into target/srcdeps
touch .inline-deps
lein with-profile -user,+1.10,+test,+plugin.mranderson/config test
Compiling 3 source files to /Users/fazekasbenedek/projects/cider-nrepl/target/classes
Syntax error reading source at (cider/nrepl/inlined_deps/toolsreader/v1v3v2/clojure/tools/reader/reader_types.clj:251:82).
Unmatched delimiter: ]
If I run antq:
clojure -Sdeps '{:deps {com.github.liquidz/antq {:mvn/version "RELEASE"} org.clojure/clojure {:mvn/version "1.11.1"}}}' -M -m antq.core
on MrAnderson, it reports:
:name | :current | :latest |
---|---|---|
com.cemerick/pomegranate | 0.4.0 | 1.1.0 |
jonase/eastwood | 0.9.9 | 1.3.0 |
lambdaisland/kaocha | 0.0-418 | 1.69.1069 |
lambdaisland/kaocha-cloverage | 0.0-32 | 1.0.75 |
leiningen-core/leiningen-core | 2.9.1 | 2.9.10 |
org.clojure/clojure | 1.10.3 | 1.11.1 |
org.clojure/tools.namespace | 1.1.0 | 1.3.0 |
rewrite-clj/rewrite-clj | 1.0.682-alpha | 1.1.45 |
If we should consider upgrading some of these old deps?
Pros:
Cons:
com.cemerick/pomegranate
is now under clj-commons/pomegranateme.raynes/fs
is now under the clj-commons/fs. Frankly, I would recommend a switch to babashka/fs instead as it has a nice API and is under active development, but that would be a switch not a bump.Lemme know how you feel, if any of this is interesting to you, I am happy to tackle this work.
C:\git\refactor-nrepl>lein source-deps && lein with-profile plugin.mranderson/config install && lein localrepo coords target/refactor-nrepl-0.2.0-SNAPSHOT.jar | xargs lein localrepo install
retrieving tools.analyzer.jvm artifact. modified dependency name: toolsanalyzerjvm modified version string: v0v6v3
modified namespace prefix: deps.toolsanalyzerjvm.v0v6v3
java.lang.IllegalArgumentException: character to be escaped is missing
at java.util.regex.Matcher.appendReplacement (Matcher.java:809)
java.util.regex.Matcher.replaceAll (Matcher.java:955)
clojure.string$replace.invoke (string.clj:105)
deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$ns_file_name.invoke (move.clj:35)
deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$move_ns_file.invoke (move.clj:76)
deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$move_ns.invoke (move.clj:98)
leiningen.source_deps$unzip_AMPERSAND_update_artifact_BANG_.invoke (source_deps.clj:99)
clojure.lang.AFn.applyToHelper (AFn.java:165)
clojure.lang.AFn.applyTo (AFn.java:144)
clojure.core$apply.invoke (core.clj:630)
clojure.core$partial$fn__4232.doInvoke (core.clj:2472)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.core$map$fn__4245.invoke (core.clj:2559)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.RT.seq (RT.java:484)
clojure.core$seq.invoke (core.clj:133)
clojure.core$dorun.invoke (core.clj:2855)
clojure.core$doall.invoke (core.clj:2871)
leiningen.source_deps$source_deps.doInvoke (source_deps.clj:123)
clojure.lang.RestFn.invoke (RestFn.java:410)
clojure.lang.Var.invoke (Var.java:379)
clojure.lang.AFn.applyToHelper (AFn.java:154)
clojure.lang.Var.applyTo (Var.java:700)
clojure.core$apply.invoke (core.clj:626)
leiningen.core.main$partial_task$fn__6071.doInvoke (main.clj:253)
clojure.lang.RestFn.invoke (RestFn.java:410)
clojure.lang.AFn.applyToHelper (AFn.java:154)
clojure.lang.RestFn.applyTo (RestFn.java:132)
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:303)
leiningen.core.main$resolve_and_apply.invoke (main.clj:309)
leiningen.core.main$_main$fn__6136.invoke (main.clj:377)
leiningen.core.main$_main.doInvoke (main.clj:366)
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.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: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)
Trying to reproduce clojure-emacs/clj-refactor.el#86 on the windows machine at work.
:dependencies [[nrepl "0.6.0"]
^:source-dep [cider/orchard "0.4.0"]
^:source-dep [thunknyc/profile "0.5.2"]
^:source-dep [mvxcvi/puget "1.1.0"]
^:source-dep [fipp "0.6.15"]
^:source-dep [compliment "0.3.8"]
^:source-dep [cljs-tooling "0.3.1"]
^:source-dep [cljfmt "0.6.4" :exclusions [org.clojure/clojurescript]]
Related to changing source-deps
to inline-deps
. I think it'd be nice if you added an alias for this that's :inline
(that'd be my preference) or :inline-dep
. That won't break backwards compatibility, but would align the name of the task with the metadata.
In re-frame-10x we go through a bit of work to delete the META-INF directories and then delete any empty directory paths left over after that.
Would it make sense to have an option to not copy those directories in, or is there some other reason why they are needed?
I had to make this change to get the mranderson tests to pass, when writing find-unbound-vars
for refactor-nrepl
:
--- i/src/refactor_nrepl/analyzer.clj
+++ w/src/refactor_nrepl/analyzer.clj
@@ -1,9 +1,8 @@
(ns refactor-nrepl.analyzer
(:refer-clojure :exclude [macroexpand-1])
(:require [clojure.tools.analyzer :as ana]
- [clojure.tools.analyzer
- [jvm :as aj]
- [passes :refer [schedule]]]
+ [clojure.tools.analyzer.jvm :as aj]
+ [clojure.tools.analyzer.passes :refer [schedule]]
[clojure.tools.analyzer.passes.jvm.validate :refer [validate]]
[clojure.tools.namespace.parse :refer [read-ns-decl]])
(:import java.io.PushbackReader))
current readme needs a big overhaul. maybe a bit less 'funny' and more informative?! :)
Occasionally after mrandersoning a file gets only half written on the disk causing compilation errors. Very likely related to the parallel file processing mranderson does on the 0.5.x branch -- however, as the problem occurred both with parallel
and claypoole
most likely mranderson itself is buggy somehow (missing with-open
maybe...?!).
Needs a test first to reliably reproduce the problem.
In https://github.com/benedekfazekas/mranderson/blob/master/src/leiningen/inline_deps.clj#L16-L42, it seems that some of the options are pulled from the CLI, some from the project map, and some from both - is this intentional?
Caught me out when I tried to include flags from the README in the project map ๐
If not, happy to write up a quick PR :)
James
depends on #35
project.clj
:dependencies [[org.clojure/clojure "1.10.0"]
^:source-dep [medley "1.1.0"]]
src/foo/core.clj
(ns foo.core
(:require [medley.core :as medley]))
(defn foo []
(medley/random-uuid))
In 0.4.9, target/srcdeps/foo/core.clj
will be the following I expected.
(ns foo.core
(:require [mranderson049.medley.v1v1v0.medley.core :as medley]))
(defn foo []
(medley/random-uuid))
In 0.5.0, medley
alias has changed and code is broken.
(ns foo.core
(:require [mrandersonf85dac82.medley.v1v1v0.medley.core :as mrandersonf85dac82.medley.v1v1v0.medley]))
(defn foo []
(medley/random-uuid))
While making some changes to MrAnderson, I was curious to know the best way to build and install locally.
I stumbled on the Makefile.
And looked at what MrAnderson does for CircleCI.
And figured things out. Maybe.
Some dev docs would be helpful for those who want to contribute to MrAnderson.
This could either be in a separate dev.md
doc or directly in the current README.md
.
Even after looking at the Makefile several times, I'm not sure I understand how to build and install a version of MrAnderson with inlined deps to my local maven repo.
I tweaked the Makefile:
-.PHONY: install inline test integration-test deploy clean
+.PHONY: boostrap-install inline test integration-test install deploy clean
# Note that `install` is a two-step process: given that mranderson depends on itself as a plugin,
# it first needs to be installed without the plugin, for bootstrapping this self dependency.
-install:
+bootstrap-install:
lein clean
lein with-profile -user,-dev install
lein with-profile -user,-dev,+mranderson-plugin install
-.inline: install
+.inline: bootstrap-install
rm target/*.jar
rm pom.xml
lein with-profile -user,-dev,+mranderson-plugin inline-deps :skip-javaclass-repackage true
touch .inline
inline: .inline
test:
lein test
integration-test:
.circleci/integration_test.sh
+install: .inline
+ lein with-profile -user,-dev,+mranderson-profile install
+
deploy: .inline
lein with-profile -user,-dev,+mranderson-profile deploy clojars
clean:
lein clean
rm -rf .inline
This seemed to work, but if it does not make sense please let me know so I can better understand.
If it does make sense I can include the change in the PR.
If adding some brief developer docs is something that interests you too, I'll follow up with a PR.
Hey again @benedekfazekas ๐
Looks like mranderson
is replacing imports that it shouldn't when it needs to rename only some classes within a package.
repro:
^:inline-dep [potemkin "0.4.5"]
- this has dependencies on riddley "0.1.12"
and clj-tuple "0.2.2"
; it's the presence of both of these that causes the issue. (I'm trying to inline clj-http "3.12.2"
, but it seems potemkin
is a smaller repro.)lein inline-deps
riddley.compiler
- mranderson
has prefixed clojure.lang.Var
etc, but these don't appear prefixed in class-deps.jar
.class-deps.jar
- there are other clojure.lang
classes present from clj-tuple
.I reckon this is something to do with prefix-dependency-imports!
using a set of packages to replace - is there anything preventing us from using exact classes instead?
Thanks again!
James
I'm not sure if this behavior is intended or not, but mranderson rewrites string literals if they contain a full namespace name. This affects this line in cider-nrepl:
https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/refresh.clj#L32
The comment above indicates that the code in cider-nrepl was written this way (constructing a keyword at runtime) specifically so that this rewriting would not happen.
The result is that cider-refresh unloads and reloads namespaces that it should not.
I recently tried to inline tools.deps.alpha
to get hotload-dependencies working again for cljr, but mranderson failed to consider these load statements in the middle of the file.
Hi
Could someone please help me with the following error:
C:\git\databot2\databot\src\za\co\resbank>lein inline-deps
project prefix: mrandersonb765aca7
retrieve dependencies and munge clojure source files
in RESOLVED-TREE mode, working on a resolved dependency tree
[clj-http "3.10.0"]
[commons-io "2.6" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpmime "4.5.8" :exclusions [[org.clojure/clojure]]]
[potemkin "0.4.5" :exclusions [[org.clojure/clojure]]]
[clj-tuple "0.2.2"]
[riddley "0.1.12"]
[org.apache.httpcomponents/httpclient "4.5.8" :exclusions [[org.clojure/clojure]]]
[commons-logging "1.2"]
[org.apache.httpcomponents/httpcore "4.4.11" :exclusions [[org.clojure/clojure]]]
[slingshot "0.12.2" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpclient-cache "4.5.8" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpasyncclient "4.1.4" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpcore-nio "4.4.10"]
[commons-codec "1.12" :exclusions [[org.clojure/clojure]]]
unzipping [ clj-http [ v3v10v0 ]]
unzipping [ httpmime [ v4v5v8 ]]
unzipping [ commons-io [ v2v6 ]]
unzipping [ potemkin [ v0v4v5 ]]
unzipping [ clj-tuple [ v0v2v2 ]]
unzipping [ httpclient-cache [ v4v5v8 ]]
unzipping [ httpasyncclient [ v4v1v4 ]]
unzipping [ httpclient [ v4v5v8 ]]
unzipping [ commons-logging [ v1v2 ]]
unzipping [ commons-codec [ v1v12 ]]
unzipping [ httpcore-nio [ v4v4v10 ]]
unzipping [ httpcore [ v4v4v11 ]]
unzipping [ slingshot [ v0v12v2 ]]
unzipping [ riddley [ v0v1v12 ]]
munge source files of riddley artifact on branch [] exposed false.
java.io.FileNotFoundException: target\default\srcdeps\riddley\compiler.clj (The system cannot find the file specified)
My project.clj
looks as follows:
(defproject za.co.resbank.databot "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
:url "https://www.eclipse.org/legal/epl-2.0/"}
:dependencies [[org.clojure/clojure "1.10.0"]
[org.clojure/data.csv "0.1.4"]
[cheshire "5.8.1"]
^:inline-dep [clj-http "3.10.0"]
[seesaw "1.5.0"]
[za.co.resbank/haverapi-java "2.1.0.0"]
[com.bloomberglp/blpapi "3.12.1-1"]
[clojure.java-time "0.3.2"]]
:main ^:skip-aot za.co.resbank.databot
:target-path "target/%s"
:profiles {:uberjar {:aot :all}}
:plugins [[thomasa/mranderson "0.5.1"]])
altho MrAnderson is mainly meant to be used on applications, inlining/shadowing their dependencies. it is possible to inline a library which has its dependencies inlined already. Wonder if this just works out of the box or breaks and if so how.
Since mranderson adds a meta now to the ns it is possible to avoid inlining already inlined stuff if needed
There was a confusing bug for a user of refactor-nrepl, who was trying to specify his own version of tools.reader. refactor-nrepl uses mranderson for shading it's version of tools.reader, but mranderson doesn't handle ClojureScript files. These got copied in whole, and caused hard to debug issues. More details are available at technomancy/leiningen#2097 (comment) and emezeske/lein-cljsbuild#439.
as means of resolving dependencies
java.lang.IllegalArgumentException: No implementation of method: :send of protocol: #'deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.transport/Transport found for class: clojure.tools.nrepl.transport.FnTransport
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541) ~[clojure-1.5.1.jar:na]
at deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.transport$eval31768$fn__31769$G__31757__31776.invoke(transport.clj:16) ~[na:na]
at refactor_nrepl.refactor$find_debug_fns_reply.invoke(refactor.clj:48) ~[na:na]
at refactor_nrepl.refactor$wrap_refactor$fn__32157.invoke(refactor.clj:57) ~[na:na]
at deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__31990.invoke(middleware.clj:17) ~[na:na]
at clojure.tools.nrepl.server$handle_STAR_.invoke(server.clj:19) ~[na:na]
at clojure.tools.nrepl.server$handle$fn__18490.invoke(server.clj:28) [na:na]
at clojure.core$binding_conveyor_fn$fn__4107.invoke(core.clj:1836) [clojure-1.5.1.jar:na]
at clojure.lang.AFn.call(AFn.java:18) [clojure-1.5.1.jar:na]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [na:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [na:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [na:1.7.0_17]
this showing up at startup may be related:
[WARNING] No nREPL middleware descriptor in metadata of #'refactor-nrepl.refactor/wrap-refactor, see clojure.tools.middleware/set-descriptor!
It looks like the com.googlecode.jarjar has been abandoned these last six years. Since then the pantsbuild developers have forked it for their own use at https://github.com/pantsbuild/jarjar
Their fork adds a few interesting features:
Might be worth a look at using! I may end up taking a look at updating it myself
A project.clj such as this:
:dependencies [[org.clojure/core.memoize "0.5.6"]
[org.clojure/core.cache "0.6.4"]]
ignores the fact that core.memoize must be processed before core.cache because pomegranate thinks core.cache does not appear in the dependencies of core.memoize.
This means core.memoize ends up with calls to clojure.core.cache
, since core.cache can be processed first.
lein plugin should be an optional wrapper really
Hi @benedekfazekas!
Opening an issue from clojure-emacs/cider-nrepl#594 because the problem does not seem to be solved:
clojure.lang.Compiler$CompilerException: clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: No reader function for tag Inf, compiling:(mranderson/inlined/parallel/v0v10/parallel/core.clj:323:31)
at clojure.lang.Compiler.load (Compiler.java:7386)
clojure.lang.RT.loadResourceScript (RT.java:372)
clojure.lang.RT.loadResourceScript (RT.java:363)
...
$ lein -v
Leiningen 2.8.3 on Java 1.8.0_191 OpenJDK 64-Bit Server VM
The tests there are running against clojure 1.10
by default.
from the conversation with @Olical on slack:
Some meta output out of mranderson, either as it runs or at the end could be useful. "here's the files I read and wrote and what I renamed inside them". I could then do my ordering work with tools.namespace on that output and spit out the full report to use in the future.
Previously, mranderson rewrote https://github.com/reagent-project/reagent/blob/master/src/reagent/debug.clj#L7 from
(defmacro log
"Print with console.log, if it exists."
[& forms]
`(when reagent.debug.has-console
(.log js/console ~@forms)))
;; to
(defmacro log
"Print with console.log, if it exists."
[& forms]
`(when mranderson048.reagent.v0v8v0.reagent.debug.has-console
(.log js/console ~@forms)))
When using mranderson 0.5.0, the namespace form isn't rewritten, it stays exactly the same as the original.
Looking at the form, it is valid ClojureScript, though it may be more idiomatic to write reagent.debug/has-console
.
I've noticed improvements elsewhere, "Expected a reagent component, not "
used to be rewritten to "Expected a mranderson048.reagent.v0v8v0.reagent component, not ", but is now left alone. I suspect this bug may be a side-effect of the change.
Hey @benedekfazekas ๐
repro:
project.clj
:
(defproject repro ""
:dependencies [^:inline-dep [tech.droit/clj-diff "1.0.1"] ; example lib compiled with Java >7
^:inline-dep [commons-codec "1.10"]] ; example lib compiled with Java <=7
:plugins [[thomasa/mranderson "0.5.3"]])
lein inline-deps
jar -tf target/class-deps.jar
In the class-deps.jar
file, we see the org.apache.commons
classes correctly prefixed under repro
, and the clj_diff
class remaining unaltered - this unaltered class may well then clash with a different version included elsewhere.
This is caused by a check in com.tonicsystems.jarjar.asm.ClassReader
from com.googlecode.jarjar/jarjar:1.3
, which throws an IllegalArgumentException
if the major number of the classfile is >51 - this exception is silently caught in com.tonicsystems.jarjar.ext_util.JarTransformer
, and the class passes through the transformer unchanged.
Suspect that #17 is the solution to this (feel free to close this one) but wanted to write up this manifestation just in case it saves someone some time!
Cheers!
James
Projects can have arbitrarily many :source-paths
. One can choose to do so for modularity reasons, or to decomplect intricacies related to Lein plugins, JDK compatibility, etc.
However mranderson only assumes one source path:
mranderson/src/mranderson/core.clj
Lines 290 to 292 in 57f01e2
So files from extra source paths will be silently dropped from a final artifact.
Make mranderson able to handle multiple source paths.
There should be some 'merging' logic: given src1/foo/bar.clj
and src2/foo/baz.clj
, only one foo
dir should be produced, it having two .clj files.
Existing mranderson consumers may be implicitly dependent on the current behavior, i.e. maybe they had more configured source paths, and dropping them was fine. Perhaps starting to include them would break things downstream which is why I'd propose to offer a mandatory option named e.g. :included-source-paths
with three acceptable values:
:first
, preserves current behavior:source-paths
, uses all :source-paths
as-is["src" "foo" "bar"]
, uses a fixed list independent of :source-paths
WYDT?
Thanks - V
currently the default is generated based on the mranderson version used to do the inlining. This actually defeats dependency isolation in theory, eg projects mrandersoned with the same version of mranderson can still clash.
As discussed here
In the referenced thread a desire to prefix the dependencies with the project name is expressed. I think this is a mistake. We want to eliminate dependency clashes, when several versions of a class is loaded into the classloader, but we don't want to load multiple versions of identical code under different names. If we use the project name as a prefix we won't be able to share the common code and the run time will grow unnecessarily large.
see clojure-emacs/cider-nrepl#247 for context
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.