https://pantsbuild.org/ logo
Join Slack
Powered by
Hi all. I added a Dockerfile to <github.com/ehiggs...
# general
p
Hi all. I added a Dockerfile to github.com/ehiggs/pants-poetry-test-repos which works nicely. I have a branch now, however, 
multiple-applications
, which seems to run into an issue with the same module name being used for two applications. With project-app/app.py and project-app-async/app.py I get the following:
Copy code
./pants run project-app:project-app
15:02:53.57 [WARN] The pex_binary target project-app has the field `entry_point='app.py'`, which maps to the Python module `app`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['project-app-async/app.py:project-app-async0', 'project-app/app.py:project-app0'].
I haven't seen how to fix this without changing the name of the file and that's not really a solution. I tried to make 
entry_point='project-app/app.py:project-app0'
but that didn't work so the error message is a bit weird that it looks like it wants me to specify which target resolution to use but then it won't let me use the target resolution (is that even a name for this?)
h
Hm that definitely should have fixed it. What do you mean by didn't work?
Alternatively, you can adjust your source roots and folder names so that the modules become project_app.app and project_app_async.app, and there is no ambiguity https://www.pantsbuild.org/docs/source-roots
Hmm, although probably in this case we should improve dep inference to know you want the one from the current dir, given this assumption about that entry_point field
Like with the sources field, file paths are relative to the BUILD file, rather than the build root.
@happy-kitchen-89482 wdyt?
e
This does fix:
Copy code
$ git diff
diff --git a/multirepo-1/project-app/BUILD b/multirepo-1/project-app/BUILD
index 1bdec0d..5250340 100644
--- a/multirepo-1/project-app/BUILD
+++ b/multirepo-1/project-app/BUILD
@@ -2,8 +2,11 @@ poetry_requirements()
 
 pex_binary(
     name="project-app",
-    entry_point="app.py",
-    zip_safe=False
+    entry_point="app",
+    zip_safe=False,
+    dependencies=[
+        ':project-app0',
+    ],
 )
 
 python_library(
➕ 1
Eric's idea seems good though going forward since a BUILD file can only own items under its fs tree.
👍 2
p
Hm that definitely should have fixed it. What do you mean by didn't work?
Copy code
Exception message: 1 Exception encountered:

  Exception: Unmatched glob from project-app's `entry_point` field: "project-app/project-app/app.py"
then if i remove the first project-app in the entry_point I get:
Copy code
ValueError: ("EntryPoint must be in 'name=module:attrs [extras]' format", 'run = app:project-app0')
h
@hundreds-father-404 What are you proposing exactly?
p
I think the proposal is that if there is ambiguity in a module name and one is in the current dir tree and the other is not, then choose the one in the current dir tree because it pretty much has to be
e
Almost. That I don't think is safe, but for the specific entry_point field, we do know that entry point must be in the current BUILD file fs tree. For a dependency, that could be anywhere in the repo; so resolving the ambiguity this way is not robust.
➕ 1
p
Yes didn't try it yet.
e
Ok. I almost sent you a PR but ran into issues with the async project. There was a typo in pyproject.toml for uvicorn (uvicown) and - I know nothing of the framework - it looked like the dep actually needed to be on uvicorn[standard] and then I ran into a bug in our poetry_requirements not dealing with extras. I'll file an issue on that one soon.
p
adding the dependencies fixes it. 😄
thanks for the help here!
n
Fwiw I ran into this last week and ended up with the same fix. Sorry I'm late to the party with the information.
p
No worries. I'm just trying out various stages of what a migrated poetry project will look like to smoke out issues. (And help 2.6.0 poetry support if these are big reports)
h
Pants 2.7 should do the right thing automatically 😎 https://github.com/pantsbuild/pants/pull/12326 Thanks @powerful-boots-1234 for flagging this edge case!
🙌 1
2 Views
Open in Slack
PreviousNext
Powered by