> 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 <qwc...@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 > https://github.com/pypa/pip/blob/develop/pip/req/req_set.py#L583 > > > >> 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 > > https://bitbucket.org/pypa/wheel/src/1cb7374c9ea4d5c82992f1d9b24cf7168ca87707/wheel/metadata.py?at=default&fileviewer=file-view-default#metadata.py-90 > > > >> 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 : ) > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
