Working on a proof of concept for our Pants usage and have run into a problem: The current structure of the PoC repo is monorepo • core ◦ core ▪︎ <code> ◦ test ▪︎ <test_code> ◦ BUILD • foo ◦ foo ▪︎ <code> ◦ test ▪︎ <test_code> ◦ BUILD Now I know this is somewhat different than the recommended layout of a BUILD in each directory and tests off to the side at a top level in their own folder. But 1) We don't need that (yet) 2) It may be too much of an extreme change for some to swallow.

core

is working fine (it's tests run and it packages from what I can tell) and it's BUILD file looks like this:

python_library(
    name = "core",
    sources = ["core/*.py"],
)

python_tests(
    name="test",
    sources = ["test/test_*.py"],
    dependencies=["core"],
)

python_distribution(
    name="dist",
    dependencies=["core"],
    setup_py_commands=["bdist_wheel", "sdist"],
    provides=setup_py(
        name='core',
        version="1.0.0",
        description='blah, blah, blah',
    ),
)

foo

which depends on core can not find core as per this error:

________________ ERROR collecting foo/test/test_cherrypy.py _________________
ImportError while importing test module '/tmp/process-executionLlK5rO/foo/test/test_cherrypy.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/home/james/.pyenv/versions/3.8.12/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
foo/test/test_cherrypy.py:11: in <module>
    from core.test_utils import token
E   ModuleNotFoundError: No module named 'core.test_utils'

foo

's BUILD looks like this:

python_library(
    name = "foo",
    sources = ["foo/jwtutils.py", "foo/jwthug.py", "foo/jwtcherry.py"],
    dependencies = ["core:core"]
)

python_tests(
    name="test",
    sources = ["test/test_*.py"],
    dependencies=[
        "core:core",
        "thirdparty/python:cherrypy"
    ],
)

python_distribution(
    name="dist",
    dependencies=["foo"],
    setup_py_commands=["bdist_wheel", "sdist"],
    provides=setup_py(
        name='foo',
        version="1.0.0",
        description='foo library',
    ),
)

My expectation is that the

dependencies

in

python_tests

make the

core

library available to foo, is this assumption incorrect?

for dependencies in the same folder, I’d try with “:core”, and “:foo”, rather than the plain versions without the colon prefix.

Thanks these aren't in the same folder though.

core

and

foo

are folders side-by-side and

foo

tests depend on a

test_utils.py

from

core

Sorry, I meant in the same BUILD file.. I was thinking of the library “foo” dependency of the “foo:dist” distribution.. for instance.

I brought this up in the thread by @tall-truck-67859 (https://pantsbuild.slack.com/archives/C046T6T9U/p1634910245074000?thread_ts=1634901465.069900&amp;cid=C046T6T9U), but this smells like a source root configuration problem. @stale-nightfall-29801, in order to import across projects, Pants needs to know project boundaries. In other words, to correct:

from core.test_utils import token
E   ModuleNotFoundError: No module named 'core.test_utils'

Pants needs to know

X

in the filesystem path

X/core/test_utils.py

. Pants call

X

a "source root". This is equivalent to a

PYTHONPATH

entry for Python. The list of "source roots" Pants knows about can be found by running

pants roots

. If

X

is not in the list printed out, you need to teach Pants about

X

as described here: https://www.pantsbuild.org/docs/source-roots#configuring-source-roots

Thanks @enough-analyst-54434 so in this example where

core

and

foo

are under

monorepo

if I'm in

~/Documents/monorepo

and I do

./pants root

and see

.

is that correctly telling me that it's

root

is at

monorepo

and it should successfully be able to find

core

and

foo

from each other ... OR should

./pants root

be showing me

. core foo

?

If the source root is just

.

, that says the file

core/bob.py

will be importable as

core.bob

.

oh so

core/core/bob.py

would be at

core.core.bob

which is not what I want ... the "outer"

core

holds the REAME, dockerfile, etc ...

core/core

is the "deployable" code

Yeah, so your source roots should be

core

and

foo

. Let us know if https://www.pantsbuild.org/docs/source-roots#configuring-source-roots doesn't get you across the finish line.

BTW I don't think a separate top-level

tests

parallel source tree is officially recommended. In the Pants repo, for example, we mostly have tests right alongside the code they test (so

src/python/foo/bar.py

is tested by

src/python/foo/bar_test.py

. Pants allows you to do this because it has the information to know not to bundle tests in the distribution, and so on. We like it because it's really easy to find the tests for some module, and vice versa.

That's ace, thanks @happy-kitchen-89482.. right now I'm trying to make things better and keep the changes most people will have to deal with down to managing a

BUILD

file at the root of each library/project folder.

I'm not sure, I think it might work

This is the kind of error I'm getting:

NoSourceRootError: No source root found for `core`. See <https://www.pantsbuild.org/v2.7/docs/source-roots> for how to define source roots.

Hmm

what is

./pants roots

reporting?

so without changes it's reporting

.

with the above changes it's reporting:

core/core

and

foo/foo

I've also had to add the tests at

core/test

and

foo/test