https://pantsbuild.org/ logo
a

abundant-analyst-12845

01/13/2023, 2:02 PM
HI have a question (more of seeking opinion on something) is there any recommended convention one can use with
confetest.py
files. As am adopting pants from a monlith repo to a mon-repo. I wondered anyone either • copying the conftest.file into each root_pattern where its required ◦ this would cause heavy duplication, which might be ok if the conftest file stays consistent • having a shared folder that is also known by pants containing a conftest file and using symlink for the other packages to point to it. • does pants have some magic that makes that easier ◦ with the potential option of overriding or enhancing package specific conftets. sorry if this is open ended
h

happy-kitchen-89482

01/13/2023, 2:28 PM
Good question. It sounds like you're assuming that your repo should have many source roots, perhaps one per project?
👍🏿 1
But have you considered merging your code into a single package hierarchy, under one source root?
That is the sort of streamlining that Pants supports well
Typically the reason to have "one source root per project" in a repo is because tooling doesn't support doing anything else
but that's not the case here
a

abundant-analyst-12845

01/13/2023, 2:34 PM
could you elaborate on what you mean
each source route would be a separate deployed artefact (for use with lambda)
e

enough-analyst-54434

01/13/2023, 3:06 PM
With Pants, physical partitioning and logical partitioning can be decoupled. You can have one and only one source root that contains many logically separate projects and artifacts. It basically comes down to a choice with how people are comfortable working.
a

abundant-analyst-12845

01/13/2023, 3:11 PM
am trying with a structure like this
e

enough-analyst-54434

01/13/2023, 3:14 PM
Understood. We just want you to understand that one option is to not structure like that. You won't lose your logical 3-part distinction, but it will make conftest sharing trivial.
a

abundant-analyst-12845

01/13/2023, 3:14 PM
where my thinking was that if I do that I get enough separation and also able to test and deploy it as separate lambda
e

enough-analyst-54434

01/13/2023, 3:15 PM
That's where you're mistaken. You can have the logical separation and test and deploy seperately ~regardless of layout.
So, its an option to physically structure differently. Just an option to consider.
a

abundant-analyst-12845

01/13/2023, 3:16 PM
maybe am feeling very slow
e

enough-analyst-54434

01/13/2023, 3:16 PM
Let me give you a concrete example. Just a sec.
a

abundant-analyst-12845

01/13/2023, 3:16 PM
am not settled on it, just wanted to explore things that will make it easier for me pants
really sorry about that.
e

enough-analyst-54434

01/13/2023, 3:20 PM
Alternate physical layout , same logical partitioning:
Copy code
src/
    addition/
    hello_world/
    math_utils/
    string_utils/
tests/
    ...
Test just libraries:
Copy code
./pants test src/math_utils:: src/string_utils::
Package just hello_world lambda:
Copy code
./pants package src/hello_world/::
The resulting tests and packages would be identical to those with your current physical layout. So this or many other physical layouts are options, keeping your logical distinctions fixed.
a

abundant-analyst-12845

01/13/2023, 3:22 PM
ah I follow what you mean meaning you would potentially only have /src as a root_pattern. ...
e

enough-analyst-54434

01/13/2023, 3:22 PM
Yeah. This is just one example. The layout is nearly arbitrary.
You may still like your layout best, for whatever reason. I just want to make it clear its not required.
a

abundant-analyst-12845

01/13/2023, 3:27 PM
that definitely an option. will try it out. And play around some of the pants commands i would run for n+ package when running
./pants package ::
and would just need to add
Copy code
python_awslambda(
    name="addition_function",
    runtime="python3.9",
    handler="lambda_function.py:lambda_handler",
)
to each "one that I want to package" in each
BUILD
file and get it working
that even more amazon
2 Views