This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-03
Channels
- # announcements (12)
- # babashka (36)
- # beginners (126)
- # calva (26)
- # cider (10)
- # clj-kondo (71)
- # cljdoc (3)
- # cljsrn (2)
- # clojure (232)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-france (20)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-serbia (4)
- # clojure-uk (6)
- # clojurescript (62)
- # conjure (5)
- # cursive (12)
- # data-science (1)
- # datomic (57)
- # deps-new (1)
- # duct (3)
- # emacs (5)
- # events (8)
- # fulcro (6)
- # graalvm (5)
- # helix (3)
- # jobs (6)
- # jobs-discuss (3)
- # kaocha (4)
- # lsp (128)
- # malli (12)
- # missionary (22)
- # off-topic (1)
- # pathom (7)
- # polylith (27)
- # quil (1)
- # re-frame (20)
- # react (9)
- # reitit (12)
- # releases (8)
- # remote-jobs (3)
- # sci (3)
- # shadow-cljs (9)
- # spacemacs (10)
- # tools-deps (7)
- # vim (7)
- # xtdb (14)
Some of you may have missed that @seancorfield has created the excellent https://github.com/seancorfield/usermanager-example/tree/polylith example project, structured as a Polylith project in the polylith
branch (the original version is in master
).
(! 793)-> clojure -Ttools install com.github.seancorfield/clj-new '{:git/tag "v1.1.331"}' :as new
Checking out: at 1bea9a5b627ca96a4589597f7cc9bf6ad16e1d49
Installed new
(! 794)-> clojure -A:deps -Tnew help/doc :fn polylith
-------------------------
clj-new/polylith
([options])
Create new Polylith project.
(! 795)-> clojure -Tnew polylith :name myname/mypoly
Generating a project called mypoly based on the 'polylith' template.
Initialized the project for use with 'git'.
(! 796)-> ls mypoly/
CHANGELOG.md LICENSE README.md bases components deps.edn development projects workspace.edn
clj-new
is the "standard" way to create new CLI/`deps.edn` projects and it supports Polylith out of the box.
Nice!
Are there plans to try to build a graalvm version of poly? Or is there something in the codebase that is a showstopper at the moment?
That is something that would be really cool to have. It should be one of the next few things to look into. I have almost no experience of GraalVM, so I need to dig into it first. It should be really nice if more people could jump in and help out with this! I don’t know if e.g. the tools.deps dependency or some other library dependency will stop the tool from being compiled with GraalVM.
@tengstrand just posted this issue: https://github.com/polyfy/polylith/issues/101 10 seconds vs 0.5 seconds
Okay, cool, then I delete “mine”!
I have a memory of tools.deps.alpha not being compatible with GraalVM but I’m not exactly sure. That could be a showstopper.
@U2BDZ9JG3 ./poly-native libs
seems to work fine; but would be great if more people could test this
How many commands have you tried? Have you tried e.g. the test
command?
Ok, interesting!
Ah, because tests run in an isolated classpath which is calculated for each project. In order to do that, we use tools.deps to resolve dependencies. I think that is where GraalVM fails. However there might be a solution to this according to this tweet
> However there might be a solution to this according to this tweet We seem to be running the most recent already:
org.clojure/tools.deps.alpha 0.12.1003
For me it's still a win, if I can run it natively for everything besides tests. ;) Need to log off for a while, cheers!
:thumbsup:
I run it in prompt
mode now, all the time, so I don't have to deal with startup times anymore.
Hi @tengstrand. I'm currently migrating a project to Polylith. A while back you wrote on Clojureverse that the poly tool would also support a configuration such that the name of a brick is equal to the interface namespace. See https://clojureverse.org/t/on-polylith-from-amazing-ideas-thread/7410/5. Is this already supported? If so, how?
Hi @U050RCD9L. I replied in the ClojureVerse https://clojureverse.org/t/on-polylith-from-amazing-ideas-thread/7410/9.
I can surely work with it, and especially the fact that polylith codebases are more similar this way I think is a valid reason.
Choices are nice, but sometimes the cost is too high. Thanks for your understanding.
FWIW, I thought the .interface
convention would annoy me a lot more than it actually does in practice. I normally require namespaces as an alias on their last segment, but with Polylith components, I just use the second-to-last segment (i.e., ignoring the .interface
part) which is guaranteed to be unique. I still don't like having a bunch of editor tabs open all called interface.clj
(!) but that's a minor issue really.