I have seen that

pex

targets won't update itself by taking into account the changes in the provided 3rd party dependencies. Whenever I run

./pants run <pex_target>

, if it fails because of some missing 3rd party dependency, it keeps failing even after I add that 3rd party dependency to say

requirements.txt

. Is this expected?

What is the name of the dependency you added to

requirements.txt

? What is the import statement in the sources of the

pex_binary

that needs to import from that dependency? Do the two align? If not, you are probably missing a module mapping. If none of the

pex_binary

sources actually import from the dependency (some form of dynamic loading is used), you will need to add an explicit dependency to the

pex_binary

or one of the

python_sources

targets it depends on. Both of these cases are described in more detail here: https://www.pantsbuild.org/docs/python-third-party-dependencies see "How dependencies are chosen". If none of that addresses your issue, we probably need more detailed information.

It's just a python package which was being imported in the script which is the source for

pex_binary

. It did complain that it can't find the imported module. I even added the target generated from

requirements.txt

using

python_requirements

as a dependency explicitly but that didn't fix it either. What "fixed" it was when I switched git branch, which is weird. Now it works, but I can't say that this is repeatable.

If you're able to provide the exact import line, and the exact edit to requirements.txt (as well as the the explicit dependency edit you tried after that) along with the complaint, I can dig further.

I think this is the issue. My

requirements.txt

is in a "non-standard" location

BUT: if you place your

requirements.txt

in a non-standard location (or give it another name via the

python_requirements(source=..)

argument), you will need to configure

pantsd

to restart for edits to the non-standard filename: see #9946.

Aha, ok. Thanks for reading those docs thoroughly and solving your problem!

I had this issue earlier too. But you fail to realize when things start going wrong. This is literally what happened

This did, in fact, bite at least one person with a file at src/requirements.txt.

https://github.com/pantsbuild/pants/pull/9946/files#r602436641

Reminder to self that I'd like to try to get the fix for this landed in Pants 2.9...pants 2.8 added the technology to avoid this huge gotcha, now just a matter of time to apply it to python_requirements and provide an acceptable deprecation experience