https://pantsbuild.org/ logo
Join Slack
Powered by
Okay there's something I'm not understanding about...
# general
b
Okay there's something I'm not understanding about 
pants repl
. Given a repo that has multiple projects, what addresses are valid to use with 
pants repl
?
Copy code
src
└── python
    ├── BUILD
    ├── project1
    ├── project2
    ├── project3
    .
    .
    .
pants repl src/python/project1
works as expected. However if 
project1
and 
project2
both have a common third party dependency, then I see Pex `ResolveError`'s. So, apparently it's not okay to do this. Which is a bummer because I wanted to 
pants repl ::
. What should I be doing instead? This is sort of a hypothetical... Not sure who would actually want to open a REPL with the entire universe in it, but someone on my team might ask to do this and I want to know what the story is 😄
c
on the actual question: I have no idea. (never used the repl goal myself.. 😬 ) relatedly, one could consider the 
pants export
to get a venv to play with..
👍 1
b
Ha! See next question!
😆 1
We have a lot of internal users of our code so I want to make sure that their workflows are minimally impacted. So I'm trying to find all the pain-points I can.
💯 1
b
Do you have separate 'resolves' per project?
If you do, it's hard to make a "whole universe" repl for such things, because they could easily depend on different versions of a single dependency, e.g. if 
project1
needs 
pydantic<2
and 
project2
needs 
pydantic>=2
, what should happen for 
pants repl ::
?
👍 2
l
You could consider defining a few command-line aliases to define repls to different universes, assuming that there is a good reason that project1 and project2 cannot coexist in the same python invocation. (It is worth looking into why you have a 
ResolveError
) https://www.pantsbuild.org/docs/reference-cli
b
So far there is only one resolve for third party requirements @broad-processor-92400
> It is worth looking into why you have a 
ResolveError
Yeah, I agree that would be good. Should have posted this earlier. Here is the tail of the actual traceback:
Copy code
pex.environment.ResolveError: Failed to resolve requirements from PEX environment @ /home/alex/.cache/pants/named_caches/pex_root/unzipped_pexes/a3363d23744e7994b84a07a9e15356d7dfe15855.
Needed cp310-cp310-manylinux_2_35_x86_64 compatible dependencies for:
 1: numpy
    Required by:
      project1 4.5.6
      project2 1.2.3
    But this pex had no ProjectName(raw='numpy', normalized='numpy') distributions.>
There are five more of these, for h5py, pyzmq, pydantic, and a few others.
l
These look like test/mock values for versions 
1.2.3
and 
4.5.6
. Oh, the projects are configured as publishable artifacts? I would expect the issue is coming from somewhere here, and may be related to this issue. It would be instructive to see what is happening in the sandbox during failure. I don't think there isn't something fundamental about the 
repl ::
that should prevent you from running it with project1 and project2 loaded unless they are actually incompatible.
b
publish artifacts
Correct! I have a 
python_artifact
target in some of these modules because they will packaged and uploaded to a local pypi server.
As an experiment, I just removed all of these targets, and 
pants repl ::
works. So what exactly is going on here?
l
There are mechanisms in pants that try to package up code that has a corresponding artifact into an artifact, assuming that this is the way that it is intended to be tested or executed, rather than using it directly. The issue with this packaging is what was reported in the testing issue. Some of the intermediate structures built with these 'local distributions' fail a kind of validation. This is something that can be fixed I think. Would you be able to report the behavior you found as an issue?
b
I looked at the github issue you linked above, and I think I'm doing something different. For me, I have no issues with running 
pants test ::
against non-packaged modules. Tests can simply run against source code in the repo.
If this is a bug I will create a minimal working example in a repo and then report the issue. 👍
👍 1
l
I think that the behavior where repl breaks by adding a 
python_artifact
target is likely a bug, but more details would be helpful to be able to figure that out. This is related to the tests issue I mention above only in what I am guessing is the root cause.
b
Yes, agreed... I will also pull your repo and see what you are looking at.
l
oh, don't worry about the issue I referred to, it will only distract you in making a compact reproduction of the issue you are facing. (I think)
👍 1
7 Views
Open in Slack
PreviousNext
Powered by