Hi, I’m seeing a weird behavior when running the

package

goal in Pants 2.4.0 🧵

Hmmm that is strange. It should exclude 2.7 due to interpreter constraints. @hundreds-father-404 any ideas?

First, could you please run

./pants --backend-packages=pants.backend.python.mixed_interpreter_constraints py-constraints path/to:python_distribution_tgt

? That will confirm this isn't coming from somewhere in your repo and it's a Pants issue

I get a

14:55:47.50 [WARN] No Python files/targets matched for the `py-constraints` goal. All target types with Python interpreter constraints: pex_binary, python_library, python_tests

for my distribution target

Ah ha. Sorry about that. @happy-kitchen-89482 do you agree it's sensible for

python_distribution

target to have

interpreter_constraints

, like we now have for

pex_binary

and

python_awslambda

? I think it will still take the transitive closure of your constraints, not just what you set on that distribution But that way you can set additional constraints + use

py-constraints

goal

Here is the debug from the package goal

I think it will still take the transitive closure of your constraints

Hm, although that does seem desirable to let you override constraints for binary types...and that's how v1 did things iirc

I'm not sure if

python_distribution

having constraints is pertinent here, it seems to me that the global constraints should still apply in this case?

@big-xylophone-43403 how about

./pants --backend-packages=pants.backend.python.mixed_interpreter_constraints py-constraints ::

?

Yeah, I don’t see any py2 constraints -

Final merged constraints: CPython<=3.8.5,>=3.7
  (These are the constraints used if you were to depend on all of the input
  files/targets together, even though they may end up never being used together in
  the real world. Consider using a more precise query or running `./pants py-
  constraints --summary`.)
CPython<=3.8.5,>=3.7
  pants-plugins/internal_plugins/packaging/__init__.py
  pants-plugins/internal_plugins/packaging/register.py
  src/python/gh/core/__init__.py... ..

Ah thanks for bumping this. Was this working previously, e.g. 2.3.0? Pants isn't doing what I'd expect and I'm trying to understand why / when that broke

I’m not sure. I’ve only tried 2.4.0 and 2.4.1. I can try

2.3.0

and see if it still breaks

That'd be great if you have a moment

I’m getting the same error with Pants

2.3.0

and the

>=3.7,<=3.8.5

interpreter constraints

Thanks, Deep. On 2.3.0, can you please try setting in `pants.toml`:

[setuptools]
interpreter_constraints == [">=3.7,<=3.8.5"]

? That option went away in 2.4.0, but I want to see if that fixes it and gives you a workaround

that worked

Great! See this option to ignore the deprecation warning if it's bothersome: https://www.pantsbuild.org/v2.3/docs/upgrade-tips#ignore-deprecation-messages-with-ignore_pants_warnings I will look into why this isn't working how we want in the meantime so that you can use Pants 2.4 and 2.5. Are you able to share the repository by chance? It's okay if over DM or you need to scrub some things

Hey Eric, do you have an update on this? Pants 2.3.0 mostly works but I would like to be on 2.4.0 to use the default module mapping functionality

Hey Deep, thanks for following up. I unfortunately did not have a chance to look into it and am heading out for vacation the rest of the week Would you be willing to make a GitHub issue with what's going on, e.g. if you have a run with

-ldebug

? Want to make sure it doesn't get lost in this thread

Hey @hundreds-father-404, sorry for the delayed response. The

./pants dependencies path/to:python_distribution_tgt

correctly show all first-party python files.

Hmmm. Then my hypothesis is likely incorrect. Can you try this to be sure? https://pantsbuild.slack.com/archives/C046T6T9U/p1623790782385700?thread_ts=1621624847.091700&channel=C046T6T9U&message_ts=1623790782.385700

Ah, I see the issue. We have a repo with multiple distribution targets. One of the distribution target config was missing the

dependencies=[]

field 🤦 Sorry for the false alarm. The CI process executes the package goal for targets that changed since our main branch. And we only ran into the issue when there were changes to the target with missing dependency declaration. Sorry for the false alarm. I confirm everything works with

2.4.0

Yay! Then that does confirm this is broken exactly how I expected. Thanks for highlighting that! It's weird to have a Python_distribution with no dependencies, but it is legal, and we need it to work properly