On 10 December 2015 at 22:28, M.-A. Lemburg <[email protected]> wrote:
> In all this discussion, please don't forget that distutils and
> setuptools differentiate between building the code and creating
> a distribution file.
> The later is not restricted to just the sdist and wheel formats.
> distutils can create a wide variety of other distribution formats
> such as MSI files, Windows .exe installers, binary in-place
> distributions. With extensions it's possible to create the
> ActiveState package format, RPMs, DEBs, Solaris PKG files and
> other formats such as our eGenix prebuilt format or web
> installers.
None of which can be installed by pip, which is the blessed
installation path, nor can most of them be uploaded to PyPI, which is
the index format we're working too.
> Apart from that it's also possible to have distutils
> completely drop the distribution file generation and go
> straight to installation after the build step, e.g.
> when not using a package manager at all.
This is something there has been clear consensus on getting away from.
Different distributions (e.g. RPM/Deb/Conda/etc) may have different
requirements around how installation is done, and getting away from
the cross product to a single interop point is a key design point.
> IMO, it would be better to use the existing "setup.py build"
> and "setup.py bdist_wheel" APIs to create a build system
> abstraction, since that'll keep the other existing distribution
> methods working in the same context, which is important since
> pip is not the only way to distribution Python packages.
Since 'build' and 'bdist_wheel' are defacto, and since setuptools is
infinitely variable... I'd like it if you could specify what you want,
rather than just referring to those commands. As it stands I've read
your mail but don't understand what is missing from the proposed
contract, nor what things are present but objectionable.
> The PEP's ideas as well as many other approaches to building
> packages can be implemented using a "setup.py build"
> and "setup.py bdist_wheel" interface ("bdist_wheel" will
> implicitly run "build").
A second key design input was that competing build system authors *do
not want* to have a setup.py in the tree of projects using them
(specifically the flit folk put this forward) - because they aren't
setuptools, and blindly running setuptools commands against their UI
won't work... and they don't want to offer all the complexity of
setuptools commands because 99% of it is irrelevant to them and their
users.
> To specifically use the PEP's mechanism, a package could be
> created which overrides and implements the PEP's build strategy,
> e.g. "pep778build" (assuming the PEP number is 778 as example).
>
> The dependency of a package on this pep778build package
> would then signal the compatibility of the package with
> the PEP's build mechanism.
That would fail to be bootstrappable, since there is no programmatic
API to get build requirements out of setuptools packages today without
triggering easy-install. At a minimum we'd have to address that before
we could consider utilising setup.py as the contract itself.
> In summary: As long as the final result of a call to
> "setup.py bdist_wheel" is a .whl file in dist/, pip should be
> able to continue working as normal (and as it does today),
> regardless of what "setup.py build" does under the hood.
pip will be able to keep working if folk don't opt into the new
system, because backwards compat with the 10's of thousands of
distributions on PyPI is a big deal - I don't see that being
deliberately broken ever.
And, a setuptools_pepxxx adapter should be easy to write - in fact I
plan to write a pbr_pepxxx adapter which will be nearly identical, as
a proof of concept - for folk that want to allow easy-install to not
be involved but still use setuptools.
-Rob
--
Robert Collins <[email protected]>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
