[Distutils] PEP for specifying build dependencies
Nick Coghlan
ncoghlan at gmail.com
Sat May 14 03:25:22 EDT 2016
On 14 May 2016 at 06:31, Chris Barker <chris.barker at noaa.gov> wrote:
> On Fri, May 13, 2016 at 1:09 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> But, the plan *is* to make wheels the standard way to build packages --
>> that will be in the next pep :-). I'm not sure I'd call it "lock down",
>> because there's nothing that will stop you running setup.py bdist_rpm or
>> whatever. But our goal is to reach the point where package authors get a
>> choice of what build system to use, and there's no guarantee that every
>> build system will implement bdist_rpm.
>
> hmm -- this really feels like mingling packaging and building.
>
> Does making sure everything builds a wheel help systems like rpm and the
> like? Honestly I have no idea.
Yes, it does. The reason is that separating the build system from the
deployment system is normal practice in those tools, but not the case
with approaches like "./setup.py install". Direct invocation of the
latter also loses semantic information about the package contents that
may be relevant for Filesystem Hierarchy Standard compliance purposes.
When the upstream installation process is instead broken up into
"build a binary artifact" and "install a binary artifact", that brings
a few benefits:
- the fact that the build system and the deployment target may be
different machines can be handled upstream
- we get a new metadata source (the binary artifact format) that can
be used in tools like pyp2rpm
- the semantic information about file types is captured in the binary artifact
Over time, what this means is that distros can move away from the
current practice of defining a packaging configuration once, and then
updating it manually when rebasing to a new upstream release, in
favour of automatically generating the downstream packaging config,
and submitting patches to the upstream project to improve the built
binary artifact as necessary (patching it locally in the meantime).
That's not something that's going to happen quickly, but you can see
the foundations of it being laid as people start trying to do things
like automatically rebuild all of PyPI as RPMs.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list