HI have a question (more of seeking opinion on som...
# general
a
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
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
could you elaborate on what you mean
each source route would be a separate deployed artefact (for use with lambda)
e
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
am trying with a structure like this
e
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
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
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
maybe am feeling very slow
e
Let me give you a concrete example. Just a sec.
a
am not settled on it, just wanted to explore things that will make it easier for me pants
really sorry about that.
e
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
ah I follow what you mean meaning you would potentially only have /src as a root_pattern. ...
e
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
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