This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-07
Channels
- # babashka (17)
- # beginners (33)
- # calva (9)
- # cider (2)
- # clj-kondo (17)
- # cljs-dev (2)
- # cljsrn (2)
- # clojars (3)
- # clojure (60)
- # clojure-australia (2)
- # clojure-europe (8)
- # clojure-gamedev (5)
- # clojurescript (27)
- # cursive (2)
- # emacs (9)
- # fulcro (8)
- # gratitude (5)
- # lsp (41)
- # malli (3)
- # meander (18)
- # pathom (5)
- # polylith (25)
- # re-frame (17)
- # reagent (1)
- # rewrite-clj (6)
- # shadow-cljs (11)
- # uncomplicate (5)
- # vim (6)
- # web-security (5)
Another bug report for the polylith docs: https://polylith.gitbook.io/poly/install/install/install-on-linux The "copy" button in the code snippet on this page doesn't work in firefox. That wouldn't be a problem, but when I highlight the text and manually hit ctrl+c, some JS on the page is interferring and preventing the copy from happening, so I can't really copy that snippet š. Tested on latest Firefox, booted up my chrome test browser and it works as expected.
We use https://www.gitbook.com/ to publish the documentation and we cannot change the page source code.
When running tests with poly test
the value of *file*
in a brick test namespace seems incorrect. It ends up being workspace-dir/<path for test namespace>
, ie missing components/<component-name>/test
Hi @U0HFRSY0M. I donāt think I really understand. Maybe you can elaborate a bit and give an example? What do you mean with *file*
? The namespaces live in each src
and test
directory in workspace-root/components
and workspace-root/bricks
so Iām not sure what you mean.
Iām referring to clojure.core/**file**
, which is bound to the file name of the namespace being loaded.
poly test
creates a classloader to run tests in isolation with respect to each project that the test is included. The poly
command runs from the top directory, loads the test namespaces and runs the tests within them one by one. You can https://github.com/polyfy/polylith/blob/master/components/test-runner/src/polylith/clj/core/test_runner/core.clj to see the whole process of running tests with Polylith.
I havenāt used *file*
before but found https://stackoverflow.com/questions/12692698/file-variable-not-working/12693068 which says it is only useful while compiling a file, and no longer useful afterwards.
Maybe the way we evaluate the test namespaces and run tests in a different classloader causes this.
I think the basic issue is that the current directory isnāt changing. This also means if the component is doing any file system access, other ran through resources, then the same path refers to different locations, depending on whether the test is run at the brick level or at the workspace level.
Maybe polylith could provide a *project-rootā var, that it sets with the root of the brick, when running a brickās tests.
Tests that cared could check if it was bound, and use it to abolutise relative paths as needed.
I donāt understand why Polylith should do that. I donāt think we are doing something wrong with running test, rather just calling the default test runner to run the tests. Isnāt it easy that adding a string variable on top of your test namespace to see where it is? I still do not understand neither the use case nor what Or if Polylith is doing something it shouldnāt
Say I want to inspect the brickās deps.edn file in a test. What is the path to that file? This isnāt my exact use case, but illustrates the problem.
I guess I could do (first (filter fs/exists? [<workspace relative path to deps.edn> <brick relative path to deps.edn>[))
but that seems error prone.
Or am I missing something obvious?
You can easily construct an absolute path from where your test namespace is, since you know where that file is. Polylithās own codebase is doing that in several places if Iām not mistaken. I would say this is the easiest way of achieving what you are trying to do. You could also include polylith/clj-api
as dependency and extract paths from the workspace data, but I would say it is an over kill.
I donāt see how to specify an absolute path if a test should work in whatever location the repo is checked out to.
I have a āpluggable backendā situation where a component implements the libraryās api, and two other components provide alternative implementations. Iām wondering how to manage this situation in polylith?
Iāve seen libraries call require
and resolve
at runtime, but that seems like itād only work as intended in a polytlith project or base, where you would only import one of the two implementations.
The polylith dev profile would instead load all the implementations and which one ends up being used at runtime becomes an implementation detailā¦
@U0CJ8PTE1 For the development project, you can use profiles to select which implementation is used by default and also how to run a REPL and/or tests using the other implementation(s).
Ah yes good point! If the api errors when it finds more than one implementation that could be pretty solidā¦
At work we have a component for http-client
(as an interface
) and we have two implementations, one for httpkit
and one for Hato (`HttpClient`). We have :+default
and :+httpkit
as the two profiles (pulling in the Hato- and httpkit-based implementations respectively) and then our projects
all specify which implementation they want.
https://polylith.gitbook.io/poly/workflow/profile you can find more information about the profiles.
What if you want to mock a component for your tests? eg you implement an external API, and you only want it to be really used is some rarely run integration tests?
One idea is to fall back to with-redef
statements in the tests to mock individual functions.