fulcrologic / guardrails

Efficient, hassle-free function call validation with a concise inline syntax for clojure.spec and Malli
Eclipse Public License 2.0
240 stars 26 forks source link

Propose bumping core.async to a more recent version to mitigate distracting warnings under Clojure 1.11 #33

Closed codeasone closed 1 year ago

codeasone commented 1 year ago

When I run kaocha against some code that depends on the 1.1.11 release of guardrails I'm seeing:

> clj -M:test --watch
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-keys already refers to: #'clojure.core/update-keys in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/update-keys
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-keys already refers to: #'clojure.core/update-keys in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/update-keys
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.passes, being replaced by: #'clojure.tools.analyzer.utils/update-vals
WARNING: update-vals already refers to: #'clojure.core/update-vals in namespace: clojure.tools.analyzer.passes.uniquify, being replaced by: #'clojure.tools.analyzer.utils/update-vals

From the dependency tree I can see that guardrails is pulling in clojure.tools.analyzer via core.async:

$ clj -X:deps tree :aliases '[:test]'
org.clojure/clojure 1.11.1
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
[...]
com.fulcrologic/guardrails 1.1.11
  X expound/expound 0.8.7 :superseded
  . org.clojure/core.async 1.3.618
    . org.clojure/tools.analyzer.jvm 1.1.0
      . org.clojure/tools.analyzer 1.0.0 # <<< HERE
      . org.clojure/core.memoize 1.0.236
        . org.clojure/core.cache 1.0.207
          . org.clojure/data.priority-map 1.0.0
      . org.ow2.asm/asm 5.2
      X org.clojure/tools.reader 1.3.2 :older-version
[...]

Bumping core.async to its latest version in my project's deps.edn resolves this issue:

{:paths [...]

 :deps {...
        org.clojure/core.async {:mvn/version "1.6.673"} ;; <<< MITIGATION
        com.fulcrologic/guardrails {:mvn/version "1.1.11"}
        ...}

 :aliases {:dev
           {:extra-paths ["dev"]
            :jvm-opts ["-Dguardrails.enabled"]}

           :test
           {:extra-paths [...]
            :extra-deps {lambdaisland/kaocha {:mvn/version "1.83.1314"}}
            :main-opts ["-m" "kaocha.runner"]}}}

But since my project doesn't depend on core.async directly, and moreover this may be an annoyance to a number of downstream projects and not just my own, I think bumping the version in the deps.edn of guardrails is the best option. I've tried this and the make tests pass okay.

Raising a PR for such a minor change seems over the top, so I'm using this issue to request the change.

See also: https://clojureverse.org/t/tools-deps-test-runner-warnings/9548

awkay commented 1 year ago

Fixed in 1.1.12

codeasone commented 1 year ago

The pom.xml in the 1.1.12 release is still referring to the older core.async version: https://github.com/fulcrologic/guardrails/blob/main/pom.xml#L80

And this is reflected in clj -Stree:

(main ✓) issue cat deps.edn 
{:paths ["src" "resources"]
 :deps {com.fulcrologic/guardrails {:mvn/version "1.1.12"}}}
(main ✓) issue clj -Stree
org.clojure/clojure 1.11.1
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
com.fulcrologic/guardrails 1.1.12
  . expound/expound 0.8.7
  . org.clojure/core.async 1.3.618  <<< STALE
    . org.clojure/tools.analyzer.jvm 1.1.0
      . org.clojure/tools.analyzer 1.0.0
      . org.clojure/core.memoize 1.0.236
        . org.clojure/core.cache 1.0.207
          . org.clojure/data.priority-map 1.0.0
      . org.ow2.asm/asm 5.2
      . org.clojure/tools.reader 1.3.2
awkay commented 1 year ago

ok, see 1.1.13...sorry bout that.