On Mon, 24 Sep 2018 at 23:03, Dan Ryan wrote:

The App/Library point is partly why we haven’t jumped on this bandwagon, the distinction is important and keeping things separate has been done intentionally. Others (such as Nick or Donald) would be in a better position to speak to this since both have written about it extensively so while pushing in that direction would require a PEP it would also be a pretty big departure from what has been the accepted approach for some time as far as I understand

I don't understand how the "app/library distinction" applies here. Setuptools is a build tool, and pyproject.toml defines how things get built. If setuptools wants to migrate from setup.cfg to pyproject.toml, how does the question of whether the project is an "application" or a "library" matter? I understand how that question might be relevant for a tool like pipenv, but for setuptools?

FWIW I don't mind where anything in particular goes, but pushing for everything to be defined by one file is not something I think is desirable if we want to maintain this separation as it will probably be confusing -- and the distinction is already subtle

I personally don't see much advantage in the "dump everything in one file" philosophy. so from a personal POV I'd prefer setuptools' config to remain in setup.cfg, but if they have reasons for wanting to move, the PEP allows them that option. But I agree - just because PEP 518 says you *can* put your config in pyproject.toml, doesn't mean that it's a good idea... Paul

Yes! bdist_wheel is supposed to be how you install packages built with setuptools on platforms without setuptools, to give you time to write its replacement. On Tue, Sep 25, 2018, 15:39 Thomas Kluyver wrote:

On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote:

...

I personally don't see much advantage in the "dump everything in one file" philosophy. so from a personal POV I'd prefer setuptools' config to remain in setup.cfg, but if they have reasons for wanting to move, the PEP allows them that option.

I've come across quite a few people who want to avoid 'clutter' in the top level of the repository. By the time you've got packaging config, test config, CI config, editor config and so on, I can see where they're coming from. I think all this mass of different files can also be confusing to newcomers. So I try to avoid creating extra files where it's easy to do so.

But in the case of setuptools, I wouldn't push for it to use pyproject.toml. It will have to continue supporting setup.py and setup.cfg forever, so all you could do is add yet another place that metadata might live, making it more complicated to understand.

Of course, I'm biased, because if setuptools uses pyproject.toml, flit looks kind of redundant. ;-)

Thomas -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/N...

On Wed, 26 Sep 2018 at 15:11, Paul Ganssle 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? Paul

On Wed, 26 Sep 2018 at 15:31, Donald Stufft wrote:

On Sep 26, 2018, at 10:23 AM, Paul Moore wrote:

On Wed, 26 Sep 2018 at 15:11, Paul Ganssle 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

You could probably implement this outside of setuptools as an extension. Clients would add a load-toml line to setup.py. Do build requirements work yet? One obstacle might be reconciling the all-strings nature of .cfg with typed toml. On Mon, Sep 24, 2018, 12:06 RonnyPfannschmidt < opensource@ronnypfannschmidt.de> wrote:

I believe contributions in the directions would be welcome, for now having something like tool.setuptools.{metadata,options,command.*} might be interesting to grow and experiment with

but whats really missing is a setuptools conributor with more than just thinly stretched time.

-- Ronny Am 24.09.18 um 17:30 schrieb Bernat Gabor:

I'm aware this might be a controversial subject, so let's have the initial discussion about it here first for full disclosure and see what people think about it. Should setuptools support pyproject.toml as configuration source or not (alternative to setup.cfg which it already does - https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setu...

The main benefit of having this would be to decrease configuration files and have build dependencies and other types of dependencies in one location. Furthermore many other packaging projects (flit, poetry) already do define their dependencies inside pyproject.toml; so would create one unified location where to look for such in the future.

The counter-argument is that "a big part of pyproject.toml was keeping that file clean" and would furthermore increase the size of that file down the line.

So what do people think? Should we encourage or discourage to have a single python project file?

I'm personally supporting build/code quality tools supporting pyproject.toml as their main configuration file.

Thanks

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.orghttps://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/C...

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/V...

Yes, furthermore PEP-517 as sdist is implemented in tox and under development for pip. On Mon, Sep 24, 2018, 20:26 Pradyun Gedam wrote:

On Mon, 24 Sep 2018, 21:46 Daniel Holth, wrote:

...

You could probably implement this outside of setuptools as an extension. Clients would add a load-toml line to setup.py. Do build requirements work yet?

Yep. PEP 518 is supported by the latest version of pip (18.0).

...

One obstacle might be reconciling the all-strings nature of .cfg with typed toml.

On Mon, Sep 24, 2018, 12:06 RonnyPfannschmidt < opensource@ronnypfannschmidt.de> wrote:

...

I believe contributions in the directions would be welcome, for now having something like tool.setuptools.{metadata,options,command.*} might be interesting to grow and experiment with

but whats really missing is a setuptools conributor with more than just thinly stretched time.

-- Ronny Am 24.09.18 um 17:30 schrieb Bernat Gabor:

I'm aware this might be a controversial subject, so let's have the initial discussion about it here first for full disclosure and see what people think about it. Should setuptools support pyproject.toml as configuration source or not (alternative to setup.cfg which it already does - https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setu...

The main benefit of having this would be to decrease configuration files and have build dependencies and other types of dependencies in one location. Furthermore many other packaging projects (flit, poetry) already do define their dependencies inside pyproject.toml; so would create one unified location where to look for such in the future.

The counter-argument is that "a big part of pyproject.toml was keeping that file clean" and would furthermore increase the size of that file down the line.

So what do people think? Should we encourage or discourage to have a single python project file?

I'm personally supporting build/code quality tools supporting pyproject.toml as their main configuration file.

Thanks

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.orghttps://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/C...

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/V...

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/K...