> since we're simply talking about name/version constraints (not platform/python)

let me clarify that... since I imagine someone might bring up markers in response...
markers allow you to vary your name/version dependencies by environment (for example, by platform and python version), 
but to be clear, it's still not a "binary" dependency declaration... i.e. the dependency is still declared by name and a version specifier alone.


On Sun, Oct 11, 2015 at 10:48 AM, Marcus Smith <qwcode@gmail.com> wrote:
 
2) after unpacking this sdist it then calls 'setup.py egg_info' to get
the full metadata for the wheel 

I wouldn't say "get the full metadata for the wheel".  it's not a wheel yet.  
`egg_info` run so we can use the pkg_resources api to find the dependencies.

 
Specifically what it does with this is
extract the setup_requires and install_requires fields

specifically, we call `requires` on pkg_resources distribution objects

 
3) eventually it actually builds the package, and this produces a
wheel (or wheel equivalent) that has its own metadata (which often
matches the metadata from egg_info in step (2), but not always)

"not always"?  not following your point
they're 2 different formats, but should contain the same essential information.
here's the wheel code that does the conversion

 
name and version before it runs egg_info, I assume that what this
means is that it's crucial for pip to have static access to dependency
information?

yes

 
It would be somewhat convenient if sdists did list their binary
dependencies:

not sure about your insertion of "binary" here.
pip is concerned with finding python project dependencies (i.e. name and version constraints) in the sdist
and then based on the current install environment, it will further constrain the wheels chosen based on architecture and python implementation.
and to be perfectly clear, none of this deals with non-python OS/Distro requirements.

 
3) if any of the packages-to-be-installed are sdists, then fetch them,
run egg_info or build them or whatever to get their real dependencies,
add these to the graph, and go to step 1

this is the pain we don't want in the future.

since we're simply talking about name/version constraints (not platform/python), It's hard to conceive that we'd agree on an sdist spec that didn't include that.

 
Do the relevant pip maintainers
even read this mailing list? :-)

I try  :  )