[Distutils] Current Python packaging status (from my point of view)
p.f.moore at gmail.com
Tue Nov 1 06:22:32 EDT 2016
On 1 November 2016 at 09:50, Nick Coghlan <ncoghlan at gmail.com> wrote:
> There's also a 4th variant, which is getting to a point where someone
> figures out a pushbutton solution for a build pipeline in a public
> PaaS that offers a decent free tier.
This, of course, is relatively easy for the simple cases (I could set
up a project that builds Windows wheels on Appveyor relatively easily
- I may well do so when I have some spare time). But the "simple
cases" are precisely those where the only difficulty is the
(relatively easy to overcome) need for a compiler. In other words, if
"pip wheel foo" works when you have a compiler, it's simple to
automate the building of wheels.
The significant problem here is the process of setting up build
dependencies for more complex projects, like scipy, pywin32, or lxml,
or even simpler cases such as pyyaml. Each such project would need
custom setup steps, and there's no easy way for a generic wheel
building service to infer those steps - the onus would necessarily be
on the individual projects to provide a script that manages the build
process (and such a script might as well be the setup,py, meaning that
we are back to the "pip wheel foo just works" case).
So the issue remains one of *someone* doing project-by-project work to
contribute scripts that cleanly handle setting up the build
environment. Whether those scripts get contributed to the project or
to a build farm project, is not so much a technical matter as a matter
of whether projects are willing to accept such pull requests.
More information about the Distutils-SIG