Fork me on GitHub

Some of you may have missed that @seancorfield has created the excellent example project, structured as a Polylith project in the polylithbranch (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
  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/	LICENSE	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.


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: 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?


I have not yet tried test; and I see now it throws a NPE :)


honestly, I expected it more to fail on libs or info and not test; heh...


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!

👍 3

I run it in prompt mode now, all the time, so I don't have to deal with startup times anymore.

😎 3

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 Is this already supported? If so, how?


Thanks for the clarification. It is not my style, but I see your point.


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.

👍 4