<div dir="ltr">+1 It would be great to start with a real setup_requires and probably would not interfere with later build system abstractions at all.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 4, 2016 at 6:33 AM Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 4, 2016, at 3:39 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On 4 May 2016 at 16:03, Robert Collins <<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>> wrote:<br>
>> The edits I'd expect to make if the conclusions I suggested in<br>
>> <a href="https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html</a><br>
>> are adopted are:<br>
>><br>
>> - change to a Python API<br>
>> - BFDL call on the file format and name<br>
>><br>
>> There is no need to issue a new sdist thing, because sdists today are<br>
>> *already* documented across PEPs 241, 314 and 345.<br>
><br>
> I already +1'ed using a Python API, but on the file name & format<br>
> side, we have the following candidates and prior art floating around:<br>
><br>
> pypa.json in PEP 516<br>
> pypackage.json in PEP 517<br>
> pydist.json in PEP 426<br>
> METADATA (Key: Value) in sdists and wheels<br>
> WHEEL (Key: Value) in wheels<br>
><br>
> My impression is that we're generally agreed on wanting to move from<br>
> Key:Value to JSON as the baseline for interoperability formats, so my<br>
> suggestion is to use the name "pybuild.json”.<br>
<br>
I'd actually prefer not using JSON for something that is human<br>
editable/writable because I think it's a pretty poor format for that case. It<br>
is overly restrictive in what it allows (for instance, no trailing comma gets<br>
me every time) and the lack of comments I think make it a poor format for that.<br>
<br>
I think JSON is great for what gets included *IN* a sdist or a wheel, but for<br>
what sits inside of a VCS checkout that we expect human beings to edit, I think<br>
not.<br>
<br>
I'm +1 on tying this to a new extension because I feel like it fundamentally<br>
changes what it means to be a Python sdist. It eliminates the setup.py which<br>
is just about the only thing you actually can depend on existing inside of a<br>
Python sdist and there are a lot of things out there that make the assumption<br>
that Python + ".tar.gz/.zip/etc" == has a setup.py and are going to be broken<br>
from it. A new extension means those tools will ignore it and we can bake in<br>
versioning of the format itself right from the start (even if the new format<br>
looks remarkably like the old format with a different name).<br>
<br>
I also believe that we can't provide a replacement for setup.py without either<br>
purposely declaring we no longer support something that people used from it or<br>
providing a way to support that in the new, setup.py-less format.<br>
<br>
One thing I remarked to Nataniel yesterday was that it might be a good idea to<br>
drop the build system aspect of these for right now (since afaict all the<br>
invested parties are currently overloaded and/or have a lack of time) and focus<br>
soley on the part of the proposal that enables us to get a real setup_requires<br>
that doesn't involve needing to do the tricky delayed import thing that the<br>
current implementation of setup_requires needs. That would net a pretty huge<br>
win I think since people would be able to use abstractions in their setup.py<br>
(even if they still use setuptools) through a simple ``import statement``,<br>
including the ability to specify what version of setuptools they need to build.<br>
People could still implement non setuptools build systems by mimicing the<br>
setup.py interface (though it will still continue to be less then amazingly<br>
documented/defined) but some of the Numpy folks from one of the previous<br>
threads stated that mimicing setup.py wasn't really the hard part of making<br>
numpy.distutils anyways. The benefit of that is not only a smaller chunk, but<br>
also the chunk that I think (and I could be wrong) that there's no real<br>
disagreement on about how to go about doing it (besides some bikshedding things<br>
like what the filename should be).<br>
<br>
-----------------<br>
Donald Stufft<br>
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>