https://pantsbuild.org/ logo
#general
Title
# general
c

curved-manchester-66006

02/08/2023, 2:48 PM
I know how to use source roots to structure a repository in a bunch of different ways. A split like
src/{python,jvm}
makes a lot of sense to me. Most of the docs for Docker, helm, etc also follow that pattern, so following them one would end up with
src/python,docker,chart,deployment}
and each deploy-able container "app" would be spread across 4 directories (plus tests) instead of having the Dockerfile or whatnot live right next to the source code. Is pants intentionally trying to nudge me towards that per backend layout as a best practice, or is it just an accident of the example in the docs?
e

enough-analyst-54434

02/08/2023, 2:54 PM
Example accident. Pants absolutely does not care how you do this!
Pants originated in a repo that used the style you outline but the ~2nd use case was layed out with top-level directory per app.
And since that time in ~2011 every imaginable layout (that's probably a bit strong) in between has been used.
For example, have you dreamed up this?: Main layout is
src/<lang>
and apps / projects define top-level dirs too (say
apps/foo/
or even just
foo/
and use BUILD files there with aliases that point into the src/ trees. This allows an app / project team to maintain "links" in their app directory to all the commonly used targets spread amongst the various src/ trees in 1 convenient short-path spot. That was the ~3rd approach all time. That was in Pants v1 though and it had more support for target aliases I think allowing you to do this. You might still be able to though.
c

curved-manchester-66006

02/08/2023, 3:02 PM
Thanks for the context!
e

enough-analyst-54434

02/08/2023, 3:03 PM
There is a lot of hulabaloo about Pants and monorepos and Pants does help with those, but Pants actually really has ~0 to do with them. It should just work - maybe with some config to guide it - with any repo of any shape.
6 Views