Fork me on GitHub
#polylith
<
2022-06-17
>
tengstrand08:06:40

If you use a late hash from master, please use the latest hash 676e8f2adae82e481863dc7dc260e61513d44e62 which fixes https://github.com/polyfy/polylith/issues/235 issue.

ikitommi09:06:15

tested, works, thanks!

ikitommi11:06:49

more thing related to our polyrepo: one of the migrated projects has java-files that need to be compiled for the project. Is there a good practise on how to init/prepare projects / bases / components with polylith? before there were Makefiles for these per repo

emccue19:06:37

:prep deps?

emccue19:06:00

:deps/prep-lib
 {:ensure "target/classes"
  :alias :build
  :fn compile-java}}

emccue19:06:14

so have a fn that calls your make files

dominic07:06:32

I've just done something like this this in my project to compile a couple of Java classes for a component - I added a similar prep step and put a build.clj file inside my component and then from the top level of the workspace I can do clj -X:deps prep :aliases [:dev] which means everything gets prepped since all the components are deps of the :dev alias. So far so good! One polylith question though: I now get a Warning 205: Non top namespace was found in <component>. warning because of the build.clj file, which is at the root of the component's folder with the namespace being just called build. Is there a way to quash this warning? Or better practice on how to set this up? Thanks!

👍 1
tengstrand08:06:39

An option could be to ignore build files at the root. You can create an issue @UEM4BH7B3 if you like.

👍 1
furkan3ayraktar12:06:47

I guess proper way would be to not include build.clj in the components folder but include it either under development project or better in the root. build.clj is not a component and I do not think it should be in the components folder. I wouldn’t add handling in Polylith to ignore it there.

dominic12:06:34

I do have a build.clj in the root to package the uberjar, but this seems like a concern of the component which relies on the Java files - especially to be able to hook into the :deps/prep-lib mechanism. Otherwise you're leaking the component’s implementation detail into the rest of the workspace, no?

furkan3ayraktar12:06:47

Hmm, do you have the build.clj in an individual component’s directory or under components directory? I would buy this if its specifically under a specific component. However, I still feel like this is a build time thing, rather than runtime, so it should live in the development project (hence workspace root). For example, what if there are more than one components that need the same build step, then the build.clj needs to be copied into those components as well?

dominic12:06:02

It's currently in the specific component folder and that is true about the repetition yeah - though I feel maybe the repetition is incidental? Different components might need different prep steps, which is why making use of the tools.deps prep mechanism made sense to me - it's specified at the “library/dependency” level and would work the same if the component was extracted out and shipped as a lib. Though I realise components aren't true isolated libraries so maybe it's the wrong way to think about it :thinking_face:

dominic12:06:38

I guess I have the same kind of uncertainty around build scripts for projects - right now it sits in the workspace root but uses set-project-root! to run as if from within the specific project’s folder, which kind assumed all projects will need the exact same build pipeline, which may not always be true

furkan3ayraktar12:06:55

Yeah, you would need a project to extract component(s) as a library. They usually wouldn’t compile alone since they would depend other interfaces. I have not enough experience with build.clj + Polylith, however, I think it’s nice to think about this before jumping into a conclusion, otherwise we’ll have too much to maintain in the Polylih codebase.

dominic12:06:23

yeah I understand and careful consideration of changes is part of why I'm loving Clojure and the ecosystem 😄 fwiw, tools.build is meant to be run as a tool, and > tools executed with -T:an-alias remove all project deps and paths, add "." as a path (https://clojure.org/guides/tools_build#_setup) i.e. the files associated with it are not intended to be considered part of your main program

dominic13:06:34

One workaround could be to add a "build" folder and then namespace the build script, that way polylith would see it as part of the top namespace I guess? But that's arguably a lie because the build script is not part of the namespace, right, you wouldn't package it in the jar

tengstrand13:06:40

This warning is there to warn people if code turns up in the wrong place. If this makes sense to people, storing the build file in each component, I think we could easily support it (exluding build files from the warning). There are always pros and cons, but I don’t think we should stop people from doing what they think is right, as long as it doesn’t violate the Polylith idea.

seancorfield17:06:54

The file does not have to be called build.clj so it could follow the naming of the component. However, whatever you call it, it's going to depend on tools.build and that depends on t.d.a and you don't want that in your program code at runtime. In a non-Polylith project, it would clearly be executed in a different classpath to the regular code - and that is the case here with clojure -X:deps prep (since each dependency uses the alias from the prep-lib data and that will typically be :build which doesn't include regular code). I believe the most pragmatic solution here is for Polylith to either ignore all top-level files in a brick, or at least ignore build.clj. Files that are not in :paths or the :test alias's :extra-paths are not relevant to poly but that might be an over-complicated approach just to ignore one or two common build-related files.

dominic17:06:08

Ignoring the top level seems easy enough and would definitely fix this particular use case (I actually named mine prep.clj to distinguish from the main build, so I'm less keen on hard coding build.clj). I'm not clear if there's any other likely use cases that warrant something more sophisticated. I'm happy to have a crack at it when I get the chance if that seems acceptable

dominic07:06:32

I've just done something like this this in my project to compile a couple of Java classes for a component - I added a similar prep step and put a build.clj file inside my component and then from the top level of the workspace I can do clj -X:deps prep :aliases [:dev] which means everything gets prepped since all the components are deps of the :dev alias. So far so good! One polylith question though: I now get a Warning 205: Non top namespace was found in <component>. warning because of the build.clj file, which is at the root of the component's folder with the namespace being just called build. Is there a way to quash this warning? Or better practice on how to set this up? Thanks!

👍 1