[Python-Dev] Status of packaging in 3.3

[Vinay Sajip]

Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> writes:

> As for me, I believe I've been rather blunt and direct in my criticism 
> in this thread: It's been said by Tarek that distutils2 authors that 
> they don't know anything about compilers. Therefore it's almost 
> unconceivable to me that much good can come from distutils2 *for my 
> needs*. Even if packaging and building isn't the same, the two issues do 
> tangle at a fundamental level, *and* most existing solutions already out 
> there (RPM, MSI..) distribute compiled software and therefore one needs 
> a solid understanding of build processes to also understand these tools 
> fully and draw on their experiences and avoid reinventing the wheel.

But packaging/distutils2 contains functionality for hooks, which can be used to
implement custom builds using tools that packaging/distutils2 doesn't need to
know or care about (a hook will do that). One can imagine that a set of
commonly used templates would become available over time, so that some problems
wouldn't need to have solutions re-invented.

> Somebody with a deep understanding of 3-4 existing build systems and 
> long experience in cross-platform builds and cross-architecture builds 
> would need to be on board for me to take it seriously (even the 
> packaging parts). As per Tarek's comments, I'm therefore pessimistic 
> about the distutils2 efforts.

This deep understanding is not essential in the packaging/distutil2 team,
AFAICT. They just need to make sure that the hook APIs are sufficiently
flexible, that the hooks invoked at the appropriate time, and that they are
adequately documented with appropriate examples.

For me, the bigger problem with the present distutils2/packaging implementation
is that it propagates the command-class style of design which IMO caused so
much pain in extending distutils. Perhaps some of the dafter limitations have
been removed, and no doubt the rationale was to get to something usable more
quickly, but it seems a bit like papering over cracks. The basic low-level
building blocks like versioning, metadata and markers should be fine, but I'm
not convinced that the command-class paradigm is appropriate in this case. The
whole intricate "initialize_options"/"finalize_options"/"set_undefined_options"
/"get_finalized_command"/"reinitialize_command" dance just makes me say,

"Seriously?".

Regards,

Vinay Sajip