This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-14
Channels
- # announcements (2)
- # aws (1)
- # babashka (18)
- # babashka-sci-dev (103)
- # beginners (165)
- # calva (51)
- # cider (8)
- # circleci (1)
- # clj-kondo (22)
- # clj-on-windows (2)
- # cljdoc (1)
- # cljfx (31)
- # cljs-dev (16)
- # clojure (81)
- # clojure-europe (71)
- # clojure-nl (7)
- # clojure-uk (11)
- # clojurescript (20)
- # code-reviews (26)
- # conjure (1)
- # contributions-welcome (1)
- # core-async (15)
- # cursive (8)
- # datomic (8)
- # defnpodcast (2)
- # eastwood (24)
- # emacs (10)
- # events (1)
- # fulcro (4)
- # funcool (31)
- # graalvm (43)
- # graphql (8)
- # honeysql (9)
- # introduce-yourself (1)
- # jobs (12)
- # kaocha (3)
- # lsp (28)
- # malli (4)
- # meander (4)
- # membrane (7)
- # off-topic (64)
- # other-languages (3)
- # pedestal (1)
- # polylith (31)
- # portal (5)
- # re-frame (4)
- # reitit (1)
- # releases (5)
- # rum (2)
- # schema (2)
- # sci (34)
- # shadow-cljs (21)
- # vscode (1)
Just starting to really use polylith after following it for acouple of years. Is there a way to create a workspace in an existing repo that only does the bare minimum without touching the gitignores? It managed to bork it and add a ton of cruft, even from things it's trying to ignore (for example it removed .lsp
and added .lsp/sqlite*.db
to gitignore, causing .lsp/.cache/sqlite.db to be added into the commit)
For now I think I'll just copy that workspace.edn, expunge the whole commit poly added automatically, and add the config manually back
Well, that didn't work so well:
$ poly info
#error {
:cause class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentMap (clojure.lang.PersistentVector and clojure.lang.IPersistentMap are in unnamed module of loader 'app')
:via
[{:type java.lang.ClassCastException
:message class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentMap (clojure.lang.PersistentVector and clojure.lang.IPersistentMap are in unnamed module of loader 'app')
:at [clojure.core$ex_info invokeStatic core.clj 4771]}]
:trace
[[clojure.core$ex_info invokeStatic core.clj 4771]
[polylith.clj.core.workspace_clj.config$dev_config_from_disk invokeStatic config.clj 9]
[polylith.clj.core.workspace_clj.core$toolsdeps_ws_from_disk invokeStatic core.clj 60]
[polylith.clj.core.workspace_clj.core$workspace_from_disk invokeStatic core.clj 126]
[polylith.clj.core.workspace_clj.interface$workspace_from_disk invokeStatic interface.clj 4]
[polylith.clj.core.command.core$read_workspace invokeStatic core.clj 52]
[polylith.clj.core.command.core$workspace_reader_fn$fn__23531 invoke core.clj 59]
[polylith.clj.core.command.core$execute invokeStatic core.clj 66]
[polylith.clj.core.command.interface$execute_command invokeStatic interface.clj 4]
[polylith.clj.core.poly_cli.core$_main invokeStatic core.clj 31]
[polylith.clj.core.poly_cli.core$_main doInvoke core.clj 7]
[clojure.lang.RestFn applyTo RestFn.java 137]
[polylith.clj.core.poly_cli.core main nil -1]]}
There is an https://github.com/polyfy/polylith/issues/160 about this problem and I will probably start working on that and other things in the weekend.
Please test the https://github.com/polyfy/polylith/tree/issue-160 and see if it works as expected. Also have a look at my comment in https://github.com/polyfy/polylith/issues/160. I updated the`.gitignore` file according to @UKFSJSM38’s comments here, and it will only be created if not already exists. @U8ZQ1J1RR
Well, that didn't work so well:
$ poly info
#error {
:cause class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentMap (clojure.lang.PersistentVector and clojure.lang.IPersistentMap are in unnamed module of loader 'app')
:via
[{:type java.lang.ClassCastException
:message class clojure.lang.PersistentVector cannot be cast to class clojure.lang.IPersistentMap (clojure.lang.PersistentVector and clojure.lang.IPersistentMap are in unnamed module of loader 'app')
:at [clojure.core$ex_info invokeStatic core.clj 4771]}]
:trace
[[clojure.core$ex_info invokeStatic core.clj 4771]
[polylith.clj.core.workspace_clj.config$dev_config_from_disk invokeStatic config.clj 9]
[polylith.clj.core.workspace_clj.core$toolsdeps_ws_from_disk invokeStatic core.clj 60]
[polylith.clj.core.workspace_clj.core$workspace_from_disk invokeStatic core.clj 126]
[polylith.clj.core.workspace_clj.interface$workspace_from_disk invokeStatic interface.clj 4]
[polylith.clj.core.command.core$read_workspace invokeStatic core.clj 52]
[polylith.clj.core.command.core$workspace_reader_fn$fn__23531 invoke core.clj 59]
[polylith.clj.core.command.core$execute invokeStatic core.clj 66]
[polylith.clj.core.command.interface$execute_command invokeStatic interface.clj 4]
[polylith.clj.core.poly_cli.core$_main invokeStatic core.clj 31]
[polylith.clj.core.poly_cli.core$_main doInvoke core.clj 7]
[clojure.lang.RestFn applyTo RestFn.java 137]
[polylith.clj.core.poly_cli.core main nil -1]]}
Anyone else who think it would be a good idea to have an example on how to use polylith interfaces and swap implementations in the poly-guide? I had an “aha-moment” when I realised how it works and the polylith structure now makes sense.
The poly tool docs have a while section on this with two implementations of a user component, one local and one remote.
Ah, I think I found it. The section about Profiles
describe how to have two components with the same interface, but with different implementations.
As I understand it, the same interface means different interface.clj
files (one for each component), but with the same function signatures.
https://polylith.gitbook.io/poly/workflow/profile
from the FAQ:
” … If any of them don’t implement the full set, then the tool will complain when running the check
, info
or test
command. …”
This confused me a bit, but when continue reading, it makes total sense:
“… The components live in two separate directories, under the components
directory, and both use the se.example.user
namespace but with different implementations in their core
namespace: ...”
Is there a reason why the realworld example has library deps in the workspace deps.edn and then under the bricks' deps.edn too?
the deps.edn in the root is for the development project
so that you can work with a single repl in the whole polylith code base
Sure, but as its' pulling in the bases and components, it seems to work just fine when those then depend on the libraries
ah, sorry - read your question a bit too fast. I understand what you mean now.
is this a similar question? might be because of Cursive @U8ZQ1J1RR
Hm, well maybe. I also noticed in the guides that part about paths, but didn't see anything about the libraries. While that question does say "libs" I understood it didn't mean really external libs
Exactly, the duplication is for it to work with Cursive. Otherwise, duplication is not needed.
If you don't use Cursive, you just put external libs in the brick deps file, not in the root.
The only duplication we have is across projects (which includes dev in the workspace deps file) for things that might differ between projects, such as database drivers.
Would it be sensible to make a comment about that, in the deps.edn of the example, and mention it on https://polylith.gitbook.io/poly/workflow/libraries?
We have this note in the Testing section.
It may be a good idea to say a few words about this in the libs section too.
Yeah, I noticed this one even before, but thought that it really is specific to the syntax for the local files, not that you also would need to duplicate the libraries
Seems like it needs to be clarified. Thanks for pointing out.