Hi, I’m trying to setup Pants in an existing mono...
# general
Hi, I’m trying to setup Pants in an existing monorepo. We have a use-case which I’m not sure is handled correctly by pants: 1. We have multiple repos, one of which is a mono-repo. 2. In repo A (not not a mono-repo), we produce a package called
is a namespace package). 3. In repo B (which is the mono-repo where I try to integrate Pants)
is in use and other packages under the
namespace are produced. I think there is a conflict since
is partially defined inside the mono-repo and partially outside. The error I get is of the following form (I get lots of them and they come in pairs:
Copy code
15:44:04.72 [WARN] The target internal_backoffice/internal/backoffice/__init__.py:../../internal-backoffice-src-sources imports `internal.db`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['//:root#internal-db', 'internal_analytics/internal/__init__.py:../internal-analytics-src-sources', 'internal_athena/internal/__init__.py:../internal-athena-src-sources', 'internal_data_science/internal/__init__.py:../internal-data-science-src-sources', 'internal_logs/internal/__init__.py:../internal-logs-src-sources', ..., 'internal_sqs/internal/__init__.py:../internal-sqs-src-sources'].

Please explicitly include the dependency you want in the `dependencies` field of internal_backoffice/internal/backoffice/__init__.py:../../internal-backoffice-src-sources, or ignore the ones you do not want by prefixing with `!` or `!!` so that one or no targets are left.

Alternatively, you can remove the ambiguity by deleting/changing some of the targets so that only 1 target owns this module. Refer to <https://www.pantsbuild.org/v2.14/docs/troubleshooting#import-errors-and-missing-dependencies>.
15:44:04.72 [WARN] Pants cannot infer owners for the following imports in the target internal_backoffice/internal/backoffice/__init__.py:../../internal-backoffice-src-sources:

  * internal.db (line: 11)
I’ve tried adding the follwing to the root
file but it didn’t fix it:
Copy code
  python_requirements: {
    "module_mapping": {
      "internal-db": ["internal.db"],
is in Pants’ req file. I’ll try to setup a repro, but not sure when I’ll be able to…
maybe u can use
attribute to tell pants that the internal package coming from repo A, only exposes the 'internal.db` module/namespace and not the entire
Copy code
python_requirements(module_mapping={"internal": ["internal.db"]})
ahh.. nvm. I didn't read everything so looks like you already tried it.. 🤦‍♂️
Thanks anyway 😛
Looks like the problem here is the opposite one - multiple packages (one published one from repo A and several local ones in repo B) provide the
package, so Pants doesn’t know which one to select for dep inference.
So, as a workaround, you can add an explicit dependency in the BUILD file, onto
And, I think dep inference could actually be made to handle this case, since you’re importing
, not
, so it should be able to not care about
itself, I think
would have to look at the code
Will give it a try now. Also, if you think it is a “good-first” PR, please LMK and I’ll try to make a repro and a fix PR in the coming days.
I’m not sure I’ve understood correctly, so I’m working on making a repro.
OK, I have a repro but I got to go. I’ll try to post it a bit later today or tomorrow morning.
Hi, I’ve made a repository with a reproduction. Note that it is on the
branch. The
(linked) has the details. Please LMK if you know how to fix it or if I can do anything to help fix it or to provide more details. Thanks 🙂
Hi, I’m done fixing all of the warnings that come up when I’m running
pants package ::
except of the issue with the namespace. @happy-kitchen-89482, could you take a look at the repro I’ve linked and let me know if it’s a mis-config by me or an uncovered use-case by Pants? Thanks in advance 🙏
Yep, looking at this now. thanks for the repro!
❤️ 1
How did you fix all the warnings? With explicit
I’ve fixed all of the other warnings, now I’ve left only with the warning of this type
@high-magician-46188 would you mind moving this convo to github discussions? I have a feeling it’s going to come up in the future, and having the conversation and fix documented would be really good. We’re running up against the limitation of Slack’s ephemerality for this sort of thing