Seems to still drop some markers

[uranusjr]

Experiementing on requirementslib, various markers disappeared. apipkg, for example, got the following from PIpenv:

python_version >= '2.7' and python_version != '3.1.*' and python_version != '3.2.*' and
python_version != '3.3.*' and python_version != '3.0.*'

Did it get them from requires_python? Because not all python_version markers are lost. pathlib2, for example, keeps it fine. (Passa even gets more because it correctly merges markers!)

[techalchemy]

Give me the source requirements for the resolution here

[uranusjr]

Confirmed those are all from python_requires. apipkg got it via

apipkg ← execnet ← pytest-xdist ← '-e .[tests]'

pytest-xdist provided those values.

I think the theoretically best option is to add an extra field to the lockfile format (and requirementslib.Requirement). Otherwise we’ll need to merge them into the markers. It’s not difficult, just messy.

[techalchemy]

I also still like this idea because it allows us to keep records of otherwise unresolvable dependencies together by just adding the extra marker. I still wonder if it makes sense to treat this special or to allow uniqueness in lockfiles the same way we do in the dep cache

As for this specific case, I assume you looked at the various ways pipenv handles that marker?

[techalchemy]

(This is related to not picking up requires_python attributes from the requirementset after resolution -- see https://github.com/pypa/pipenv/blob/master/pipenv/patched/piptools/repositories/pypi.py#L396 for info)

[uranusjr]

Implemented requires_python pickup in d339019 (with a cache), and merging them into markers in 2d90438. This should do it for now. (The logic can use some improvement, the markers are a bit ugly now.)