Is there any way to ignore conflicting versions of dependencies when generating a lockfile? Sadly, Apache Beam depends on an ancient version of dill -- this is known, and work is planned to move off of it. In the meantime, there are runtime options to avoid problems with that (e.g. using

cloudpickle

instead of

dill

) but no build time options to not require dill<0.3.2. I tried setting a requirement for dill==0.3.8 in both requirements.txt and constraints.txt, but still get the following error, that I'm hoping to ignore:

pip: ERROR: Cannot install apache-beam and dill==0.3.8 because these package versions have conflicting dependencies.
pip: ERROR: ResolutionImpossible: for help visit <https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts>
pip:  
pip:  The conflict is caused by:
pip:      The user requested dill==0.3.8
pip:      apache-beam 2.61.0 depends on dill<0.3.2 and >=0.3.1.1
pip:      The user requested (constraint) dill==0.3.8
pip:  
pip:  To fix this you could try to:
pip:  1. loosen the range of package versions you've specified
pip:  2. remove package versions to allow pip attempt to solve the dependency conflict

Pex has this ability (the

--exclude

and

--override

options), but they are not used by Pants yet. Doing so is not hard, but would require a little modeling. Basically, deciding how you specify these excludes/overrides in a BUILD file.

Yeah I think they either belong at the resolve level (override this dependency version for this resolve) or the requirement level (override the transitive dependency version requirement for this requirement). I think doing it at the requirement level would be nice because it's the smallest surface area (so you're least likely to accidentally ignore a new version incompatibility), but probably requires features from the solver that don't exist. Given we just get pex's --exclude and --override, resolve level makes sense to me

If they’re at the requirement level then how do you handle collisions? (e.g., two requirements with different, conflicting, overrides)

I'm just imagining a situation where Library A depends on Library B < 1.0 Library C depends on Library B >= 1.0, <2.0 but for some reason or another a developer knows it's safe and wants to set Library B to 1.0. Then Library D comes around and depends on Library B < 1.0. I think it would be really cool to have a way to express overrides such that the new dependency fails until reviewed by a human. Basically, instead of saying "Override Library B to 1.0" you would say "Override Library A's dependency on library B to 1.0 and then let the solver find a suitable version". Practically, though, I think that's much harder to implement properly, so I'm not opposed to just tossing an override at the resolve level similar to resolve to constraints file