[Distutils] Comments on PEP 426

[Daniel Holth]

On Thu, Aug 29, 2013 at 1:30 PM, Oscar Benjamin
<oscar.j.benjamin at gmail.com> wrote:
> On 29 August 2013 18:11, Daniel Holth <dholth at gmail.com> wrote:
>> It probably makes sense for some version of bdist_wheel to be merged
>> into setuptools eventually. In that system pip would document which
>> setup.py commands and arguments it uses and a non-distutils-derived
>> setup.py would have to implement a minimal set of commands to
>> interoperate. This is basically where we are today minus the "minimal"
>> and "documented" details.
>>
>> The alternative, not mutually exclusive solution would be to define a
>> Python-level detect/build plugin system for pip  which would call a
>> few methods to generate an installable from a source distribution.
>>
>> It doesn't exist yet mostly because the pip developers haven't written
>> enough alternative build systems. There is no strategic reason for the
>> delay.
>
> I thought that the list in the PEP seemed reasonable:
>
> python setup.py dist_info
> python setup.py sdist
> python setup.py build_ext --inplace
> python setup.py test
> python setup.py bdist_wheel
>
> Most projects already have a setup.py that can do these things with
> the exception of bdist_wheel. The only ambiguity is that it's not
> clear whether the expectation is *exactly* those invocations or
> whether any other command line options etc. would be needed.
>
> Can it not simply be documented that these are the commands needed by
> current packaging tools (and return codes, expected behaviour, ...) to
> fit with the current bleeding edge infrastructure?
>
> I would have thought that that would be good enough as a stop-gap
> while a better non-setup.py solution awaits.

I don't think defining the plugin interface will cause build systems
to be written. I think it has to go in the other direction. Otherwise
we would be uninformed about the real needs of the plugin interface.
There are not currently large numbers of better non-distutils-derived
systems clamoring for easy pip interop.