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