> On Sep 26, 2018, at 10:23 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Wed, 26 Sep 2018 at 15:11, Paul Ganssle <p...@ganssle.io > <mailto:p...@ganssle.io>> wrote: >> >> Sorry it's taken me a while to respond in this thread, but I think I'd >> like to slightly reframe the question away from `setuptools` >> specifically - considering that certain requirements are standardized in >> the Core Metadata specification, might it make sense to add those to the >> core spec for `pyproject.toml`, so that there's a single standard way >> for various tools to look for the install dependencies of a project? >> >> >> This would involve adding something like a `distribution.requires` and >> possibly `distribution.requires-python`, which would map more or less >> directly to `Requires-Dist` and `Requires-Python`. >> >> Similarly there is an argument for adding the `Provides-` metadata to >> this table. >> >> That said, I can think of some reasons not to do this - for example in >> some cases you may want to generate the dependencies in some way as part >> of the build script (possibly from another format that is more >> convenient), which means that even in the most ideal conditions we >> couldn't say, "You should *only* be using the [distribution] table to >> specify your dependencies". > > That's a much broader question, and while I think it warrants > exploration, it's going to be hard to get consensus - not least > because there's *only* really setuptools and flit in the "build tool" > area at the moment, so it's hard to be sure we're covering all bases. > > One other thing I'd like to standardise, because pip uses it > internally, is specifying setuptools' `--python-tag` option. At the > moment, pip's PEP 517 implementation can't support that, because > there's no tool-agnostic way to specify it. I'm ignoring the problem > right now, but I assume that the use case for pip setting > `--python-tag` is real, and will need addressing properly under PEP > 517. But without a PEP revision/extension, or some highly > tool-specific special casing, I don't know how. > > Maybe we need some lightweight way of "trying out" new common > parameters, so we can do a proof of concept implementation *before* > committing to a final spec revision? >
The reason pip is using —python-tag is because in the pip cache we had the problem where you had libraries that had optional C modules for CPython and pure python fallbacks on like PyPy. If you installed it on pip first, it would cache a pure Python version of the wheel, and then tried to install it on CPython, it would see that a compatible wheel was already cached (since a pure python wheel is compatible!) and not build a cached version with the C libraries built. This wouldn’t be a problem if all projects were very careful about making sure that their projects produced wheels with properly scoped tags, but unfortunately it’s really easy to get into the state above, and really hard to make sure that your wheel produced on PyPy is not tagged as a universal wheel (plus you get into the fact that some projects were last built before wheels were even a thing) so the most robust thing to do was treat cached wheels as ALWAYS specific to the current interpreter, regardless of what the producer thinks. One option for doing this without the —python-tag is to simply edit the wheel to adjust the name and the internal metadata so that we manually override the produced wheel tag. Alternatively we could move the tag out of the wheel filename, and instead add it into the directory structure, so instead of <hash>/foo-1.0-cp27-none-any.whl, we’d get <hash>/cp27/foo-1.0.py2.none.any.whl. Of course we can also just add general support for —python-tag too, any of these would work I think.
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/5QU23TDS62PFCKRNS6CPPWCV3QOWN3S2/
