Re: [Python-ideas] support toml for pyproject support
On Mon, 8 Oct 2018 09:26:12 -0400 David Mertz wrote: > I agree here. I briefly urged against using the less used TOML format, but > I have no real skin in the game around packaging. I like YAML, but that's > also not in the standard library, even if more widely used. Agreed with David. Also, please note that one argument against YAML is its complexity, which logically also entails implementation complexity (and therefore makes it less likely that a YAML implementation would enter the stdlib). Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
If I had the energy to argue it I would also argue against using TOML > in those PEPs. I partook in that discussion, and I still have no idea why TOML was chosen, over, say, a defined subset of YAML, or a slightly extended JSON. But the folks that were highly invested and putting the work in made a choice, so here we are. But if it’s in the PEPs, it seems time to define a version used ( 1.0 would be good, but often that’s actually pretty arbitrary) and get an implementation into the stdlib. If the TOML folks don’t think it’s stable enough for that, I’ve got to wonder if it was a good choice! We’re have enough trouble with really slow adoption of the new ways of doing packaging, not even providing the tools seems to really defeat the purpose. -CHB ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
On Mon, Oct 8, 2018 at 4:53 AM Erik Bray wrote: > If I had the energy to argue it I would also argue against using TOML > in those PEPs. I personally don't especially care for TOML and what's > "obvious" to Tom is not at all obvious to me. I'd rather just stick > with YAML or perhaps something even simpler than either one. > I feel the same way. (Somebody was requesting extensive TOML support for mypy and was also waving those PEPs in front of us.) -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
On Mon, Oct 8, 2018 at 12:49 PM Jimmy Girardet wrote: > > Hi, Hi Jimmy and welcome! :) > > I don't know if this was already debated but I don't know how to search > in the whole archive of the list. > > > For now the adoption of pyproject.toml file is more difficult because > toml is not in the standard library. > > Each tool which wants to use pyproject.toml has to add a toml lib as a > conditional or hard dependency. > > Since toml is now the standard configuration file format, it's strange > the python does not support it in the stdlib lije it would have been > strange to not have the configparser module. > Let's wait till TOML hits 1.0 before adding it to the standard library. It's still at 0.5 right now. I am personally in favor of adding a standard library module for TOML, after it hits 1.0 and there's some stability after the release. > I know it's complicated to add more and more thing to the stdlib but I > really think it is necessary for python packaging being more consistent. > TOML has a fairly unambiguous specification so I don't think the choice of library should really affect what data gets loaded. If there are differences across implementations, due to the TOML specification unintentionally being ambiguous, please do file an issue on GitHub. :) > > Maybe we could thought to a readonly lib to limit the added code. I don't think that would be as helpful as possibly a round-tripping parser-writer combination but I'll refrain from pushing for that *right now*. > > > If it's conceivable, I'd be happy to help in it. > > > Nice Day guys and girls. > > Jimmy Cheers, Pradyun (pip maintainer, TOML Core member) > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
I agree here. I briefly urged against using the less used TOML format, but I have no real skin in the game around packaging. I like YAML, but that's also not in the standard library, even if more widely used. But given that packaging is committed to TOML, I think that's a strong case for including a library in stdlib. The PEP 517/518 authors had their reasons that were accepted. Now there is broad ecosystem that is built on that choice. Let's support it. On Mon, Oct 8, 2018, 8:03 AM Anders Hovmöller wrote: > > >> He's referring to PEPs 518 and 517 [1], which indeed standardize on > >> TOML as a file format for Python package build metadata. > >> > >> I think moving anything into the stdlib would be premature though – > >> TOML libraries are under active development, and the general trend in > >> the packaging space has been to move things *out* of the stdlib (e.g. > >> there's repeated rumblings about moving distutils out), because the > >> stdlib release cycle doesn't work well for packaging infrastructure. > > > > If I had the energy to argue it I would also argue against using TOML > > in those PEPs. I personally don't especially care for TOML and what's > > "obvious" to Tom is not at all obvious to me. I'd rather just stick > > with YAML or perhaps something even simpler than either one. > > This thread isn't about regretting past decisions but what makes sense > given current realities though. > > / Anders > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
>> He's referring to PEPs 518 and 517 [1], which indeed standardize on >> TOML as a file format for Python package build metadata. >> >> I think moving anything into the stdlib would be premature though – >> TOML libraries are under active development, and the general trend in >> the packaging space has been to move things *out* of the stdlib (e.g. >> there's repeated rumblings about moving distutils out), because the >> stdlib release cycle doesn't work well for packaging infrastructure. > > If I had the energy to argue it I would also argue against using TOML > in those PEPs. I personally don't especially care for TOML and what's > "obvious" to Tom is not at all obvious to me. I'd rather just stick > with YAML or perhaps something even simpler than either one. This thread isn't about regretting past decisions but what makes sense given current realities though. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
On Mon, Oct 8, 2018 at 12:23 PM Nathaniel Smith wrote: > > On Mon, Oct 8, 2018 at 2:55 AM, Steven D'Aprano wrote: > > > > On Mon, Oct 08, 2018 at 09:10:40AM +0200, Jimmy Girardet wrote: > >> Each tool which wants to use pyproject.toml has to add a toml lib as a > >> conditional or hard dependency. > >> > >> Since toml is now the standard configuration file format, > > > > It is? Did I miss the memo? Because I've never even heard of TOML before > > this very moment. > > He's referring to PEPs 518 and 517 [1], which indeed standardize on > TOML as a file format for Python package build metadata. > > I think moving anything into the stdlib would be premature though – > TOML libraries are under active development, and the general trend in > the packaging space has been to move things *out* of the stdlib (e.g. > there's repeated rumblings about moving distutils out), because the > stdlib release cycle doesn't work well for packaging infrastructure. If I had the energy to argue it I would also argue against using TOML in those PEPs. I personally don't especially care for TOML and what's "obvious" to Tom is not at all obvious to me. I'd rather just stick with YAML or perhaps something even simpler than either one. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
On Mon, Oct 8, 2018 at 2:55 AM, Steven D'Aprano wrote: > > On Mon, Oct 08, 2018 at 09:10:40AM +0200, Jimmy Girardet wrote: >> Each tool which wants to use pyproject.toml has to add a toml lib as a >> conditional or hard dependency. >> >> Since toml is now the standard configuration file format, > > It is? Did I miss the memo? Because I've never even heard of TOML before > this very moment. He's referring to PEPs 518 and 517 [1], which indeed standardize on TOML as a file format for Python package build metadata. I think moving anything into the stdlib would be premature though – TOML libraries are under active development, and the general trend in the packaging space has been to move things *out* of the stdlib (e.g. there's repeated rumblings about moving distutils out), because the stdlib release cycle doesn't work well for packaging infrastructure. -n [1] https://www.python.org/dev/peps/pep-0518/ https://www.python.org/dev/peps/pep-0517 -- Nathaniel J. Smith -- https://vorpus.org ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] support toml for pyproject support
Hi Jimmy, and welcome, On Mon, Oct 08, 2018 at 09:10:40AM +0200, Jimmy Girardet wrote: > Hi, > > I don't know if this was already debated but I don't know how to search > in the whole archive of the list. > > > For now the adoption of pyproject.toml file is more difficult because > toml is not in the standard library. It is true that using third-party libraries is more difficult than using the std lib. That alone is not a reason to add a library to the std lib. > Each tool which wants to use pyproject.toml has to add a toml lib as a > conditional or hard dependency. > > Since toml is now the standard configuration file format, It is? Did I miss the memo? Because I've never even heard of TOML before this very moment. Google Trends doesn't really support your assertion that TOML has become "the standard" for config files: # compare TOML, JSON and YAML https://trends.google.com/trends/explore?q=%2Fg%2F11c5zwr35t,%2Fm%2F05cntt,%2Fm%2F01w6k2 although it is trending upwards: https://trends.google.com/trends/explore?q=%2Fg%2F11c5zwr35t > it's strange > the python does not support it in the stdlib lije it would have been > strange to not have the configparser module. We don't even ship a YAML library, and that seems to be far more popular than TOML. On the other hand, we do ship a plist library. > I know it's complicated to add more and more thing to the stdlib but I > really think it is necessary for python packaging being more consistent. > > > Maybe we could thought to a readonly lib to limit the added code. What is a readonly lib? -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] support toml for pyproject support
Hi, I don't know if this was already debated but I don't know how to search in the whole archive of the list. For now the adoption of pyproject.toml file is more difficult because toml is not in the standard library. Each tool which wants to use pyproject.toml has to add a toml lib as a conditional or hard dependency. Since toml is now the standard configuration file format, it's strange the python does not support it in the stdlib lije it would have been strange to not have the configparser module. I know it's complicated to add more and more thing to the stdlib but I really think it is necessary for python packaging being more consistent. Maybe we could thought to a readonly lib to limit the added code. If it's conceivable, I'd be happy to help in it. Nice Day guys and girls. Jimmy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
