plain-fireman-49959
11/03/2021, 1:55 PM./pants dependencies projects/example
doesn't return any dependency, I tried both poetry_requirements
and python_requirements
. If pants can indeed support this setup, do you have any examples of open source monorepo?witty-crayon-22786
11/03/2021, 4:12 PM./pants roots
reporting each of your project directories, likely by configuring marker files in this case (as in the âMultiple top-level projectsâ example)plain-fireman-49959
11/03/2021, 4:16 PM./pants roots
and I get all the roots I expect (some are "double nested" like one.two.project_1
,one.two.project_2
etc)witty-crayon-22786
11/03/2021, 4:18 PM./pants dependencies
. for the purposes of smoketesting though, iâd recommend running ./pants dependencies ${some_python_file}
, as then you can compare the dependencies to the imports more easilyplain-fireman-49959
11/03/2021, 4:21 PM./pants deps
output, I should see that a.py depends on one.b
correct? I ran ./pants tailor
before checking for depswitty-crayon-22786
11/03/2021, 4:28 PM./pants roots
report in this case?plain-fireman-49959
11/03/2021, 4:28 PMone.b
as I'd like it to..
one/a
one/b
one/c
witty-crayon-22786
11/03/2021, 4:29 PMone
are problematicone.a
, etc, youâd want only .
in that listplain-fireman-49959
11/03/2021, 4:30 PMwitty-crayon-22786
11/03/2021, 4:30 PMone/a
is that one/a
will be stripped from the import pathimport A
plain-fireman-49959
11/03/2021, 4:31 PMmarker_filenames = ["pyproject.toml"]
in pants.toml
(removed it for this screenshot)witty-crayon-22786
11/03/2021, 4:31 PMsrc/<lang>
layoutfrom one.a import A
, then you donât want one/a
to be a sourceroot, as that will be stripped.plain-fireman-49959
11/03/2021, 4:33 PMa
be a project with its own pyproject and set of deps?witty-crayon-22786
11/03/2021, 4:36 PMand canÂmostly: when dependencies overlap between projects, Pants will report them as âambiguousâ, and youâll need to declare them in be a project with its own pyproject and set of deps?a
BUILD
files. so it will work, but IMO itâs more of a transitional state on the way to having fewer sets of thirdparty deps declared, and only when different parts of the repository need different depslogging
module, that will also be reported as ambiguity, and so those projects will need to explicitly declare those dependenciesplain-fireman-49959
11/03/2021, 4:54 PMwitty-crayon-22786
11/03/2021, 4:56 PMI imagine that by discovering dependencies by looking at imports as pants does, I can have a ârootâ pyproject and run goals for each subproject by âdownloadingâ only its set of dependencies, I can package and distribute them independently with only their dependencies. The main problem Iâm having though is that we mostly run all this project from one monolithic entry point/service.yea, all of this is correct. you will be able to run tests using only the relevant subset of the dependencies, and only when those dependencies have changed. itâs fine to then have a smaller number of
pex_binary
targets: i.e., things that are actually deployed./pants test one/a/some/specific/file.py
will run with the minimum dependencies of that file, while packaging your monolithic deploy binary will pull everything in.pex_binary
for your monolith will depend on them, and always be up to dateplain-fireman-49959
11/03/2021, 4:59 PMwitty-crayon-22786
11/03/2021, 6:10 PMhundreds-father-404
11/03/2021, 9:03 PMpyproject.toml
, check out https://www.pantsbuild.org/docs/python-third-party-dependencies for Pants's conceptual model of third-party dependencies and how it creates a single "universe" of dependencies that any file can pull fromwitty-crayon-22786
11/03/2021, 10:22 PMone/a/a/a.py
⌠if you want to import as from a.a import A
, then you would need a source root at one/a
(one/a/a/a.py
has the source root chopped off to get a/a.py
, which would be imported as from a import a
or from a.a import A
). but anyway: just think of the source roots as the prefix to chop off before calculating the import path.plain-fireman-49959
11/04/2021, 10:21 AMjust think of the source roots as the prefix to chop off before calculating the import path.This explains it perfectly! So if I want to keep the org's namespace I could do something like
src/org/a/main.py
src/org/b/lib.py
, src
would be a source root and I would be able to from org.b.lib import lib_b
. There will be one pyproject.toml
at root level and each target (a
and b
) can have BUILD
files for testing, packaging, linting, etc. I think it makes sense, I'll try this setup today, thank you all!hundreds-father-404
11/04/2021, 2:51 PM