search

sarugaku / passa

Resolver implementation and toolset for generating and interacting with Pipfile and Pipfile.lock.
ISC License
53 stars 12 forks source link

Requirement conflicts when mixing named and non-named specification for a package #34

Closed uranusjr closed 6 years ago

uranusjr commented 6 years ago 
[packages]
jinja2 = { git = 'https://github.com/pallets/jinja' }
flask = '*'

Jinja2 would have only one candidate (the VCS checkout), but this cannot satisfy Jinja2 (>=2.10) (specified by Flask). I’m not sure how this should be handled… maybe the checkout needs to read the package’s version. But how should we store it… just using Requirement.specifiers?

uranusjr commented 6 years ago

OTOH, pip does not support URL-based (including VCS) dependencies (PEP 508, PEP 440), so if we ever find ourselves in this situation, it must be caused by a user specification. I guess we can simply trust the user to know what their doing, and simply allow an unnamed candidate to always satisfy a named requirement.

techalchemy commented 6 years ago

Right, I don't think this is a bug. However, if the user specifies the VCS url in dev-packages then it would be a bug to prefer it over the actual resolution if they don't specify --dev

techalchemy commented 6 years ago

The implementation there might not be totally right -- you may want to always prefer editable requirements but not necessarily always prefer a requirement just because it has a link

uranusjr commented 6 years ago

It is not right in general, but right for the currently available in Python packaging (i.e. pip). I’ll do better when pip can do better :p