https://pantsbuild.org/ logo
Join Slack
Powered by
I’m not changing any 3rd party dependencies but pa...
# development
m
I’m not changing any 3rd party dependencies but pants decides to resolve constraints every few runs. I’m using pants 2.7.1. Update: apparently it happens when I switch from running pants within a virtualenv and outside, is it supposed to happen?
h
When you say "running pants within a virtualenv" you mean not via the 
./pants
runner script?
m
I mean running the 
./pants
script from within virtualenv shell
h
Oh hm, that's not really a use case we've thought about. What is the reason for doing that? I can see how that might invalidate a resolve, since the interpreter selection process might see this as a new interpreter. @enough-analyst-54434 thoughts?
e
IIUC running inside a venv changes PATH. If that's part of the configured interpreter search path, and it is by default, mutating it should invalidate a bunch of work.
That said, it should be a zig-zag mutation and you should be able to flip in and out of the venv between two sets of cached results.
To be precise, by "running inside", I mean activating (or deactivating) a venv.
m
OK, now I understand
a
I've also noticied weirdness w/ constraints. e.g. just now:
Copy code
╰─➤  ./pants package ::                                                                                                                                127 ↵
16:35:09.17 [INFO] Initializing scheduler...
16:35:09.34 [INFO] Scheduler initialized.
⠐ 8.67s Resolving 3rdparty/constraints.txt
⠐ 9.13s Resolving 3rdparty/constraints.txt
it's resolving the constraints... twice?
h
Hmm, I think that might be a UI artifact? @witty-crayon-22786 thoughts?
w
that’s likely because you have binaries with different 1) platforms, 2) interpreter constraints
➕ 1
a good thing to check is what the tool in https://blog.pantsbuild.org/python-3-migrations/ reports: it can summarize the intepreters used within your repository. fewer distinct sets is better in general
m
Copy code
$ ./pants py-constraints --summary
Unknown flag --summary on global scope
Use `./pants help` to get help.
19:38:29.52 [ERROR] Unknown flags --summary on global scope


(Use --print-stacktrace for more error details and/or --no-process-execution-local-cleanup to inspect chroots and/or -ldebug for more logs. See <https://www.pantsbuild.org/v2.7/docs/troubleshooting> for common issues. Consider reaching out for help: <https://www.pantsbuild.org/v2.7/docs/getting-help.>)
w
@melodic-thailand-99227: hm. do you have that backend enabled? it isn’t by default, sorry
need to add 
--backend-packages=pants.backend.python.mixed_interpreter_constraints
to enable it (either in 
pants.toml
, or on the CLI temporarily)
m
@witty-crayon-22786 what should I look for?
w
sorry: my comment was somewhat specific to @ambitious-actor-36781’s output showing multiple resolves happening: you may not have more than one resolve happening in your repository.
but if you were to run 
./pants --backend-packages=pants.backend.python.mixed_interpreter_constraints py-constraints ::
, you’d want to see a small number of total distinct intepreters
a
Just noticed this happen. pants 2.8 list of commands that I ran: • 
pants build //src/python/service_a:docker-image
(no constraints calculated) • <edit pants.toml to add DOCKER_HOST to [docker] section (this should probably be a default?)> • 
pants build //src/python/service_b:docker-image
(no constraints calculated) • 
pants build //src/python/service_c:docker-image
<< constraints calculated
w
does 
py-constraints
report different interpreter constraints for any of those targets?
h
Run 
./pants py-constraints //src/python/service_a:docker-image
and so on for each target
2 Views
Open in Slack
PreviousNext
Powered by