I'm having an issue where my source is here:

container/package-a/bin/main.py

When creating pex_binary it's using the following import path

container.package_a.bin.main

instead of just

package_a.bin.main

. How can I fix this? 🧵

Usually this will be related to source roots: https://www.pantsbuild.org/2.19/docs/using-pants/key-concepts/source-roots What does

pants roots

say for your repo?

pants.toml:

[source]
root_patterns = ["/"]

container/package-a/BUILD:

poetry_requirements(
    name="poetry",
    resolve="package-a",
)

container/package-a/BUILD

python_sources()

pex_binary(
    name="pex_binary",
    entry_point="main.py",
    resolve="package-a",
)

Ah, it sounds like the latter might be more like what you want. That sounds like a bug in the docs, that we should fix. Can you find where you saw it specifically?

but I can say switching it to use

marker_filenames = ["pyproject.toml"]

yields a different result. This time though the import path is too short, i.e.

bin.main

when it should be

package_a.bin.main

Oh, right, hm. It looks like

container

needs to be the source root, so

root_patterns = ["container/", "...anything else..."]

would be closer

I'm going to try hard coding the actual root pattern... 🙂

Although... I don't know if

package-a

with a hyphen will behave as expected.

I'll report back shortly.

at the very bottom

Oh, I think that's trying to say "for this specific example", but is definitely ambigious. Do you feel like contributing a fix to add an extra qualifier to that and the one above? (Not a problem if not!) https://github.com/pantsbuild/pants/blob/42ff1dd86a7c3b370a2802df272d27ff0bb42ce3/docs/docs/using-pants/key-concepts/source-roots.mdx#L354

@broad-processor-92400 I started to think of wording and I'm actaully lost. I don't know in what context those two are the same.

Ah, hm, maybe something like: Pants can deduce the appropriate root using

pyproject.toml

as a marker file:

[source]
marker_filenames = ["pyproject.toml"]

For this example, this pattern is equivalent to using the build root

/

as the fully-qualified pattern:

[source]
root_patterns = ["/"]

And then similar for the earlier one, basically flip the code blocks to have the pattern version first, and then expand that to be the fully-qualified file paths second. Do you think that's clearer/would've avoided your confusion?

> Ah, hm, maybe something like @broad-processor-92400 not really helpful. and I'm not sure how to clarify it.

okay, no worries! docs are hard 😅

yeah. Do you hvae any warnings about dependencies that can't be inferred? Which module isn't found?

No warnings. When I call this it returns 0 deps

pants dependencies container/package-a/bin:pex_binary

hm, it should definitely at least have

main.py

🤔 The first thing I'd check is if the hyphen is causing issues; is it easy to

mv package-a package_a

as an experiment, and see if that works better?

This fixed it...

diff --git i/utility/company-devops/company_devops/BUILD.pants w/utility/company-devops/company_devops/BUILD.pants
index db46e8d6c9..fcc078087a 100644
--- i/utility/company-devops/company_devops/BUILD.pants
+++ w/utility/company-devops/company_devops/BUILD.pants
@@ -1 +1 @@
-python_sources()
+python_sources(resolve="company-devops")
diff --git i/utility/company-devops/company_devops/azure_devops/BUILD.pants w/utility/company-devops/company_devops/azure_devops/BUILD.pants
index db46e8d6c9..fcc078087a 100644
--- i/utility/company-devops/company_devops/azure_devops/BUILD.pants
+++ w/utility/company-devops/company_devops/azure_devops/BUILD.pants
@@ -1 +1 @@
-python_sources()
+python_sources(resolve="company-devops")
diff --git i/utility/company-devops/compdev/BUILD.pants w/utility/company-devops/compdev/BUILD.pants
index 0c23d586da..2db6047e1a 100644
--- i/utility/company-devops/compdev/BUILD.pants
+++ w/utility/company-devops/compdev/BUILD.pants
@@ -1,10 +1,11 @@
-python_sources()
+python_sources(resolve="company-devops")
 
 pex_binary(
     name="pex_binary",
     entry_point="main.py",
+    dependencies=[
+      "utility/company-devops/company_devops",
+      "utility/company-devops/compdev",
+    ],
     resolve="company-devops",
 )
diff --git i/utility/company-devops/compdev/commands/BUILD.pants w/utility/company-devops/compdev/commands/BUILD.pants
index db46e8d6c9..fcc078087a 100644
--- i/utility/company-devops/compdev/commands/BUILD.pants
+++ w/utility/company-devops/compdev/commands/BUILD.pants
@@ -1 +1 @@
-python_sources()
+python_sources(resolve="company-devops")

ah, that's not great that it was silently ignored, despite the explicit

main.py

reference as an entry point. Can you file an issue that cross-resolve

pex_binary

entry_point

s don't work. As a minor fix-up, now that you've been guided to update the resolves, does removing the explicit dependencies work?

@broad-processor-92400 I literally just tried that because my of my curiosity and it works without explicit dependencies!

Is it fair to say that pants hasn't been optimized to onboard repos that require 100's of custom resolves?

Yeah, I think so

I can file a bug

Thank you!

you're welcome. If you want to collab on the docs update, I'm game. As a newcomer to pants I can't discern the difference between the two root sources arguments. My main feedback, is I'm not even sure why it's valuable to mention that the two are the "same" -- even though they're not really in all circumstances. Because when reading the docs, my original instinct was to use the marker filenames and when I read that they were identical, I updated my pants.toml.

Yeah, I see where you're coming from. I think the intention is to have both the pattern version and then "expand" the pattern into the equivalent set of explicit paths (like "here's what the short-hand means"), but that doesn't come across and, as you say, is maybe not valuable.

@broad-processor-92400 totally get it. I think what would be most useful is an expansion on how the two differ and where they're the same and elaborating wherever necessary. Because for new people (or at least for me), it reads, "we are literally identical in outcome, so feel free to use either one."