Fork me on GitHub

How easy/hard would it be to check (on the issue-66 branch) that each brick's deps.edn contains all the necessary :deps for external libraries? I'm not sure how you'd make non-brick ns :require entries to libs, but spotting that a brick is missing :deps that are needed would be a really useful thing.


I asked the same question to @U1G0HH87L two days ago. It looks like without mapping the library namespaces to actual dependencies, that would be hard. However, Polylith already calculates all the non-brick imports and requires and you can view with the ws command.


Yeah, that looks like it could at least spot a namespace that doesn't seem to come from a declared dependency?


Yeah, but its hard be exact. Library names are different than the namespace names sometimes. I noticed Java libraries are more consistent then Clojure ones. What do you think @U1G0HH87L , can we do something smart here?


What exactly is the :lib-imports data? Is that just namespaces that are requires, regardless of dependencies?


Yeap, all namespaces imported or required from a brick that are not a namespace from another brick.


Ah, OK. It got my hopes up! 🙂

😀 3

You can list all library dependencies for e.g. the deployer project with this statement: poly ws get:projects:deployer:lib-deps: {:src {"me.raynes/fs" {:size 11209, :type "maven", :version "1.4.6"}, "metosin/malli" {:size 43722, :type "maven", :version "0.5.1"}, "mvxcvi/puget" {:size 15930, :type "maven", :version "1.3.1"}, "org.clojure/clojure" {:size 3914649, :type "maven", :version "1.10.3"}, "org.clojure/tools.deps.alpha" {:size 60953, :type "maven", :version "0.12.1003"}, "org.slf4j/slf4j-nop" {:size 4020, :type "maven", :version "1.7.32"}, "slipset/deps-deploy" {:size 6205, :type "maven", :version "0.1.5"}}}


To see which bricks the project uses, execute poly ws get:projects:poly:component-namesand poly ws get:projects:poly:base-names . For each component, e.g. the deployer component, execute poly ws get:components:deployer:namespaces (replace components with bases if a base) and get the :imports from each namespace. Here we can see that we import the deps-deploy.deps-deploy namespace from the deployercomponent. The last thing to do is to detect used libraries (and in that way figure out the missing ones) and comparing these namespaces with the existing namespaces for the used libraries (e.g. by looking in the ~/.m2/repositories): {:src [{:file-path "/Users/joakimtengstrand/source/polylith/components/deployer/src/polylith/clj/core/deployer/interface.clj", :imports ["polylith.clj.core.deployer.core"], :name "interface", :namespace "polylith.clj.core.deployer.interface"} {:file-path "/Users/joakimtengstrand/source/polylith/components/deployer/src/polylith/clj/core/deployer/core.clj", :imports ["clojure.string" "deps-deploy.deps-deploy" "" "polylith.clj.core.api.interface" "polylith.clj.core.file.interface" "" "polylith.clj.core.version.interface"], :name "core", :namespace "polylith.clj.core.deployer.core"}]}


I'm not so concerned about projects, TBH. I'm more concerned with bricks that don't have all their lib deps -- I know that those deps can be provided by projects, including development, but I think it's a useful optional check to provide a warning for a brick's imported libs that don't seem to be in the deps. I can probably just do it manually by comparing the output of these commands for a given brick:

# what it had -- no deps:
clojure$> ws get:components:messaging-sdk:lib-deps
# what it imports:
clojure$> ws get:components:messaging-sdk:lib-imports
{:src [""
# add missing libs:
clojure$> ws get:components:messaging-sdk:lib-deps
{:src {"com.stuartsierra/component" {:size 19006,
                                     :type "maven",
                                     :version "1.0.0"},
       "http-kit/http-kit" {:size 191910, :type "maven", :version "2.5.3"},
       "org.clojure/tools.logging" {:size 12219,
                                    :type "maven",
                                    :version "1.1.0"}}}
Probably just something I should get into the habit of double-checking (but it would be nice for it to be automatic).


Yes, the trick is to automatically map the namespaces used by the library to the list of imports. It should be possible to do. I will add it to my todo list and look into it when I have time.


Would it be possible to look into a dependency JAR and extract the root namespace(s) from it? This way you can compare what you have vs missing.


I had the same idea. Maybe there are libraries that can do similar things!

seancorfield16:07:12 has functions to find Clojure namespaces in JAR files -- but it assumes source files: I don't think it works if the sources aren't present. That would cover most Clojure libraries though. Plus you could filter out certain clojure.* namespaces and java.* classes as being provided by the "platform". Other Java classes might be straightforward since the .class filename and path will directly match the class name and package. You'd definitely want to cache all of that mapping though rather than performing that deconstruction every time.