Is it something akin of Lein’s prep-tasks, which pre-compile some Clojure code to be able to use it in Java? Didn’t realize this exists in Deps. =/

Actually the opposite https://clojure.org/guides/deps_and_cli#prep_libs

Hmm… Nice one. So far I deal with it in my single component with a single shared utility Java class with the help of compile-java function in the ws-level build script. The function contract is simple, it expects a single argument — the brick name. Then I call it like this: clojure -T:build:dev compile-java :brick components/utils.

IIUC, ultimately this can be simplified and kinda idiot-proofed with clj -X:deps prep (as per https://clojure.org/reference/clojure_cli#deps_prep). The problem with :deps/prep-lib approach in my case, though, is that if I want to make clj -X:deps prep to work (at the top level, i.e. for the development project), I need to somehow point it to the build script.

If my build script is at scripts/build.clj, then how can I reference it within a components/utils’s deps.edn alias extra-paths/-deps?

Ok, so I was able to reach the point where I get Error building classpath. The following libs must be prepared before use: [platform/utils] error for the clj -X:dev:deps prep (from the ws level, i.e. for the development project), after I converted my scripts subdir into a Deps project and making the utils component depend on it via a :local/root. And I now get the same error for the clojure -T:build:dev compile-java :brick components/utils command. Now I’m stuck.

If I comment-out the :deps/prep-lib in my utils component’s deps.edn I at least am able to run previous command (from the root) that compiles Java sources in it.

Oh now you are on the same page with me 😅

Yeap. Maybe this is a real deal, i.e. issue with nested Deps projects that were not accounted for in Deps? I wish @U04V70XH6 could advise here, but he already mentioned a while ago that WS doesn’t use pre-compiled Java (apart from libs). Out of luck here. =/

I've been summoned! So... there's a lot to unpack here but I'll start by saying that the bricks' deps.edn are not "complete" deps files in the sense that the Clojure CLI expects -- because bricks don't declare dependencies on other bricks, only on third-party libraries.

Only projects have "complete" deps.edn files, so that's the only place you can hang -X:deps prep -- and :deps/prep-lib is designed to be used for a complete library (which bricks are not).

So... You could use it at the top-level (i.e., the development project) and it could rely on your :build alias (or some other alias) and some function and :ensure some specific directory.

However! Think about what the whole prep-lib concept is about: it is for a one-time preparation step for a (third-party) library you are using.

So... I'll ask @U7JHWBCS0 the question: is this mixed Clojure/Java library external to your Polylith project or is it part of your project? I'm reading your question as the latter -- which is not a use case for prep-lib because you would presumably be changing your Java code and needing to recompile it each time, rather than a one-shot preparation. In which case, just putting something in your build.clj script to recompile the Java whenever you need/want to is the right approach here.

Damn, it makes a lot of sense now! The CLI simply can’t see the dependency between the two bricks (there is none), consumes the list of deps from the development project, and then traverses it in some specific order that cannot be changed (or, at least, I don’t know how — simply swapping items in the :extra-deps vector doesn’t change anything).

:extra-deps takes a hash map and they are inherent unordered.

Yeah, I meant :extra-paths vector, of course. Pesky typo.

So, yeah, it looks like my previous approach is the single feasible one. Just use a compile-java step in your build.clj script or bb task, do it once, and that’s it. Thank you, Sean!

I only use :extra-paths for test folders. I use :extra-deps for bricks. But, yeah, build.clj and compile-java whenever the Java code changes (again, assuming the Java code is in the Polylith project?).

I tend to use both :extra-paths and :extra-deps in non-`:test` profiles for IDEs/editors compatibility. It shouldn’t hurt anyway. The classpath will be the same.

> assuming the Java code is in the Polylith project? Correct, sir.

Even Cursive supports :extra-deps in Polylith now. Pretty sure that was the only hold-out previously.

I’m still on 2020.1.3 though. 😑

Probably will update soon and get rid of this “extras”.

Sorry 🙂

If you want tooling support with Python, that should be your best option right now as far as I know.

I might be a bit biased, but: Yes 😄 Some differences from Clojure are that the Polylith tooling is built on top of package & dependency management tools like Poetry, Hatch or PDM. Also, there is a python-specific "theme" that is recommended to use. It will organize the bricks a bit differently. This is because Python tooling in general has poor support for the dynamic kind of folder structure that we have in Clojure. If you haven't already, have a look at the Python Polylith docs: https://davidvujic.github.io/python-polylith-docs/ And I'm here if there is any questions or feedback.

I have also helped out some Python teams via zoom/meet to get things started quickly and resolving any issues.

Can a polylith repo have and share dependencies between Clojure/Python?

Clojure runs on the JVM and if you want to share code from another language (as a library) then it must be compiled to Java bytecode. Another option is to use https://www.graalvm.org to share code between languages. I don't know, but maybe you can use https://www.jython.org to generate bytecode.

Interesting,https://github.com/clj-python/libpython-clj, but I don’t know what “magic” it uses.