On Wed, 26 Sep 2018 at 15:31, Donald Stufft <don...@stufft.io> wrote: > > > > 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> 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.
Yeah, the specific case has a number of possibilities (it's not an area I know much about though, so I'd defer to others for a good solution, probably). OTOH, a general tool-agnostic way to do what `--python-tag` does (or indeed any of the flags listed in https://wheel.readthedocs.io/en/stable/#defining-the-python-version) might be useful, too. For the PEP 517 implementation, I'll probably just hack the filename as a short-term fix (with a #TODO comment as a reminder if anyone feels like producing a better solution). Thanks for the explanation. Paul -- 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/4NUMWDT7MVWMVJEAWB3INPG4QACK35QY/
