Fork me on GitHub

@tengstrand @furkan3ayraktar not sure if you noticed, cursiveolin commented on - he seems to need some info to proceed, are you able to point him in the right direction?


Thanks for pointing out, will have a look!


I will not have time to look into this today @U08BJGV6E, but maybe we can fix this together. The only reason we added the test paths was to make Cursive happy, so if Colin thinks we can get rid of them (if he makes the other changes) then I see no problem with that. I haven’t fiddled around with the module solution, but do you agree with me that it could work @U08BJGV6E?


let me think through what's needed again


Okay, I think I have the context again


So you're saying that this bit in the top-level deps.edn isn't really needed:

:test {:extra-paths ["components/user/test"


Is that right?


Maybe, at least that was how I interpreted Colin’s answer, but haven’t tested.


Oh I mean can that bit be removed from the poly perspective? Is that the bit that you only added to make Cursive happy?


Yes, so that Cursive recognises the test code. The poly tool will pick them up through the :local/root syntax.


Right, so if I understand it correctly, 1. We'd like Cursive to follow those :local/root dependencies that point to modules (which could be added manually to handle Colin's case) and pick up source/test paths from them 1. This could still obey the selected aliases in the Clojure Deps tool window, so if a :local/root dep is not in any aliases that are currently selected, its paths would not appear as source/test roots


Hmm, actually, that isn't correct, let me rethink


Adding the bricks and projects as modules manually like I did, or perhaps through some new convenience feature solves the marking of folders as source/test roots.


What it does not solve is click-to navigation between bricks, because bricks do not reference each other directly, only through being included together in a project


Tagging @U0567Q30W here in case this is helpful


Added a on the issue. @tengstrand if you have some time I'd appreciate if you could review it lest I'm misunderstanding something.


I think it should be “… selected which `:local/root` references a `brick` “, or maybe I misunderstood something.


That last sentence was for the transitive case, where the alias references a project, which in turn references bricks


In case I want to launch a repl that only has one specific project's deps


Not sure that's a valid usecase


The poly tool expects you to list all the bricks it needs, not projects that point to bricks.


you mean, in development aliases, right?


I'm migrating a relatively big codebase to polylith and the only test failure I'm stuck on is related to resources. I have migrations in the resources directory of the base, and in the repl I'm able to access these resources, but when I run poly test, I get a nil pointer exception, seemingly indicating the resources directory is not found for the project. I set up a small repro repo to demonstrate the issue: Am I missing something or is this resauce lib used by ragtime incompatible with the way polylith manages projects? I added a println with io/resource and it is found


I can repro that but don't yet understand why it fails. I updated the workspace deps.edn file to:

{:aliases  {:dev {:extra-paths ["development/src"]
                  :extra-deps {org.clojure/clojure {:mvn/version "1.10.3"}
                               org.clojure/tools.deps.alpha {:mvn/version "0.12.1003"}

                               poly/cli {:local/root "bases/cli"}}}

            :test {:extra-paths ["bases/cli/test"]}

            :poly {:main-opts ["-m" "polylith.clj.core.poly-cli.core"]
                   :extra-deps {polyfy/polylith
                                {:git/url   ""
                                 :sha       "b32f37589f12c6be3955bf23f5bae9c55639468f"
                                 :deps/root "projects/poly"}}}}}
So I could test via :dev and that also fails the same way -- so io/resource can find the resources but however Ragtime's load-resources works, it can't find resources in a directory.


I have digged a little deeper and replaced ragtime by resauce


(println "EXISTS!" (io/resource "migrations/postgres/20210301000000-test.up.sql"))
  (println "WORKS!" (resauce/resources "migrations/postgres"))
  (println "SLURP!" (slurp (first (resauce/resources "migrations/postgres/20210301000000-test.up.sql"))))
  (resauce/url-dir (first (resauce/resources "migrations/postgres")))
only the last statement (url-dir) fails, I am able to find and slurp but url-dir throws a nil pointer with poly test and works in the repl


@U04V70XH6 I think I found a good hint about what is going on: REPL:

Decomposing url-file
str path:  file:/home/yenda/resource-ws-issue/bases/cli/resources/migrations/postgres
URI:  #object[ 0x299267f3 file:/home/yenda/resource-ws-issue/bases/cli/resources/migrations/postgres]
getPath:  /home/yenda/resource-ws-issue/bases/cli/resources/migrations/postgres
Decomposing url-file
str path:  file:bases/cli/resources/migrations/postgres
URI:  #<URI file:bases/cli/resources/migrations/postgres>
getPath:  nil


Strange, since both clj -A:dev (REPL) and clojure -M:poly test would be run from the same directory (`user.dir`) -- I would have expected resauce (and Ragtime) to be able to work with relative paths on the classpath.


The repl uses clojure.lang.DynamicClassLoader and poly tests use #<URLClassLoader [email protected]>


The dynamic class loader returns a full path: 0x21f8749d file:/home/yenda/resource-ws-issue/bases/cli/resources/migrations/postgres the URLClassLoader doesn't: #<URL file:bases/cli/resources/migrations/postgres> and (.getPath (URI. (str url))) ends up being nil here


@U04V70XH6 there's been a new version of ragtime published 5 days ago that uses a new version of resauce which doesn't have that issue. The issue was caused by that url-file function:

(defn- url-file [url]
  (File. (.getPath (URI. (str url)))))
without absolute path the URI .getPath was returning nil I think there an oddity with polylith there as that was never an issue before


Oh, cool, so you updated and it's all working now?



👍 1

@tengstrand it looks like the forum has been hijacked by spammers the last couple months.


I don't think anyone uses the forum and hasn't done for a while (well, except spammers 🙂 ), so it probably shouldn't be linked to from the docs anymore (and perhaps should be shut down?)


I think I went and looked at it once and it had nothing useful in it -- and that was ages ago. I can't even remember the URL 🙂


The plan has been to shut it down for a while. I have written an


The Polylith Forum has now been deleted. The reason was that the content was outdated and lately also hijacked by spammers.

👍 4

The Polylith Forum has now been deleted. The reason was that the content was outdated and lately also hijacked by spammers.

👍 4