Reflection: would it make sense to warn/err in cas...
# general
c
Reflection: would it make sense to warn/err in case there is an unconstrained requirement? šŸ§µ
I noticed that if I added
extra_requirements.add = ["strawberry-graphql"]
and tried to generate a lockfile for that tool, it ā€œwouldnā€™t finishā€ (I interrupted it after 1000s). When I included some version constraints,
extra_requirements.add = ["strawberry-graphql>=0.95.1,<0.96"]
to it, I got a helpful message hinting at why it took so long to lock (I think) without the version constraints:
Copy code
Resolving dependencies...

  SolverProblemError

  The current project's Python requirement (>=3.6) is not compatible with some of the required packages Python requirement:
    - strawberry-graphql requires Python >=3.7,<4.0, so it will not be satisfied for Python >=3.6,<3.7 || >=4.0
  
  Because no versions of strawberry-graphql match >0.95.1,<0.96
   and strawberry-graphql (0.95.1) requires Python >=3.7,<4.0, strawberry-graphql is forbidden.
  So, because pants-lockfile-generation depends on strawberry-graphql (<0.96,>=0.95.1), version solving failed.
So, also including
interpreter_constraints = [">=3.7,<3.10"]
it created my lockfile in seconds (or less, real quick any way).
The thing is here, when I add something new to try out, Iā€™m lazy and canā€™t be bothered looking up what version is the latest to use for the constraints.. so itā€™s likely Iā€™ll try doing this again in the future.. šŸ˜›
h
This isn't always the case that it's an issue afaict. But imo we should probably not make behavior change because we're changing to Pex (pip) soon for generating lockfiles
šŸ‘ 1