melodic-carpenter-3961302/08/2023, 9:18 AM
due to multiple pinned versions of bcrypt (3.2.2 vs 4.0.1), but only have a single pinned version (3.2.2) in my top-level requirements. How would I use pants to debug the constraints for each package similar to
so that I can work out where the issue is coming from?
refined-addition-5364402/08/2023, 9:22 AM
melodic-carpenter-3961302/08/2023, 10:51 AM
and could in theory invoke the PEX separately and retry. Interestingly there are no files within the
, so for instance I cannot view
How would I go about trying to find the pants dependency or sub-dependency that is causing the issue from here?
refined-addition-5364402/08/2023, 12:21 PM
melodic-carpenter-3961302/08/2023, 12:43 PM
with the environment variable
and inspect the output. This is useful for instance when pip is taking a long time to resolve requirements as I can identify situations where pip is attempting to download lots of different versions of packages and testing to see if they satisfy all the package version constraints (in the dependency tree). With pants it is a black box
and/or setting the environment variable
doesn't give me any more insight other than knowing that pants is attempting to generate a specific lockfile and the time taken so far to do so - is there a way to get more detail here that I've missed in the pants docs?
On the flip side when pip installs everything (which could theoretically include version conflicts which it then warns about), I would see what the dependency tree is for a given virtual environment using deptree and/or pipdeptree which together I can work out where potential version conflicts are coming from.
Any help on how to do this sort of debugging using pants would be most appreciated 🙂 🙏
but this gives me a list of all dependencies, but does not attribute each to a particular pants resolve and/or give any version constraints (in the case of
./pants dependencies --transitive ::
was previously taking me 5+ minutes for a relatively modest set of top-level dependencies and re-running the command appears to then take roughly the same amount of time, which feels like I am not benefiting from using pants vs using vanilla pip and is annoying as alternatives such as pipenv (via Pipfile) allow more control over when to lock. Is there a way to make pants smarter here, particularly if no source files have been changed?
4. How do I increase the verbosity of the pants wrapped pip process so that I can identify what is happening during the lock process (e.g. similar to
) rather than wait for a failure to spit out an error?
pipenv lock --verbose
refined-addition-5364402/08/2023, 1:04 PM
enough-analyst-5443402/08/2023, 1:11 PM
but you won't need that in this case. Your output snippet above shows
in the requirements list Pants invokes Pex with; so the error message is dead on. These 2 conflicting requirements are coming directly from top level user requirements in your repo.
... bcrypt==3.2.2; python_version >= "3.6" bcrypt==4.0.1; python_version >= "3.6" ...
melodic-carpenter-3961302/08/2023, 1:21 PM
which feeds into
resolve). I've came to the conclusion that it is not a top-level dependency that I have specified that is requesting
and causing the conflict and is instead some sub-dependency hence why I am interested in getting more verbose output of the pants locking process.
enough-analyst-5443402/08/2023, 1:22 PM
melodic-carpenter-3961302/08/2023, 1:29 PM
, however I do have a
target with a different resolve in a
file in the same directory as a pipenv
, however this is not currently causing me issues.
How would I filter all targets in
to list only
pants dependencies --transitive
targets, ideally matching
dependencies in my repo currently)
enough-analyst-5443402/08/2023, 1:34 PM
is a potential red flag unless your repo is truly consumed by Python 3.6 and greater. If not, the marker can likely be narrowed and, likewise `interpreter_constraints`narrowed - this all helps to shrink the lock solve space and speed up locks.
python_version >= "3.6"
melodic-carpenter-3961302/08/2023, 1:57 PM
just in case it was relevant, but my main problem is with the default lockfile.
Due to the fact I could only find one entry for
in the source code I suspected that the conflict is being pulled in as a subdependency of another one of the top-level python requirements.
is valid as we are using interpreter constaints of
python_version >= "3.6"
interpreter_constraints = [">=3.7.13,<=3.8.0"]
, but I guess this marker was likely added before using pants to manage dependencies. Does it harm to keep it in?
enough-analyst-5443402/08/2023, 2:02 PM
melodic-carpenter-3961302/08/2023, 2:04 PM
enough-analyst-5443402/08/2023, 2:04 PM
melodic-carpenter-3961302/08/2023, 2:09 PM
enough-analyst-5443402/08/2023, 2:10 PM
melodic-carpenter-3961302/08/2023, 2:40 PM
. I've included a screengrab of the
file in case you can provide some further insight into the behaviour
I'll rerun the
./pants --keep-sandboxes=always -ldebug generate-lockfiles --resolve=python-default
enough-analyst-5443402/08/2023, 2:44 PM
are getting used along with the other requirements where the other bcrypt version is defined to create the lock and it's that that we need to debug.
melodic-carpenter-3961302/08/2023, 2:45 PM
enough-analyst-5443402/08/2023, 2:46 PM
melodic-carpenter-3961302/08/2023, 2:52 PM
enough-analyst-5443402/08/2023, 3:00 PM
melodic-carpenter-3961302/08/2023, 3:13 PM
with some possibly sensitive stuff removed.
file that feeds as much of the monorepo as possible under the
enough-analyst-5443402/08/2023, 3:24 PM
requirements targets do default to a resolve of
- which the docs claim they do, then those targets and your
`pipenv_requirements`target do name different resolves. Clearly? those 2 different resolve targets are getting mixed into the process that creates the
lock and that's why you see 2 bcrypt requirements being passed to Pex in the lock failure snippet you posted. That sounds buggy if so, but I'm also pretty "multiple-resolves at the Pants level" ignorant - I did all the Pex support work to implement locking, but nothing at the Pants layer.
targets, test targets, `python_distribution`targets) never mix resolves and this may be towards your
targets an explicit
just to rule out defaulting weirdness. I'll truly bow out at this point.
melodic-carpenter-3961302/09/2023, 7:07 AM