conditional, transitive dependencies may not be added to Pipfile.lock

[belm0]

Issue description

• Pipfile contains a package dependency on package A (trio).
• package A has a conditional os_name dependency on packace B (cffi, os_name=='nt')
• Pipfile.lock is generated on an OS not matching the conditional
• attempts to sync Pipfile.lock from OS matching os_name will fail to install the needed dependency

Expected result

If I have an os_name conditional in my Pipfile proper, pipenv will still add the corresponding dependency in my Pipfile.lock, even if the os_name doesn't match. Likewise I'd expect a conditional dependency coming from a package to always be added to Pipfile.lock.

[techalchemy]

This falls into the 'would be nice' category, but in general we respect platform restrictions on upstream dependency declarations not because we want to, but in practical terms because it's proven very hard to implement the alternative approach with our current resolver stack. I'd be curious to know if you have any success using https://github.com/sarugaku/passa as your resolver for this case

[matteius]

I spent some time on this last night studying what is happening with respect to the current pip resolver, and basically the platform marker transitive dependencies get filtered out -- modifying pip to not do this revealed that it in many cases has to build the sdist to get the package metadata, which is problematic when that package cannot be built on the local platform. What I find incredibly interesting is that requirementslib has its own setup_py metadata builder that doesn't actually require building the package (in fact it refuses to even execute string interpolation to avoid arbitrary code execution) in order to get the metadata. The problem though would be actually marrying up that functionality with what pip does -- we would need pip to want to support this use case and change the assumption that a resolved package has to be an installable package on that platform.