[Python-Dev] Status of packaging in 3.3

[Dag Sverre Seljebotn]

On 06/23/2012 02:27 PM, Vinay Sajip wrote:
> 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.

Of course you can always do anything, as numpy.distutils is a living 
proof of. Question is if it is good design. Can I be confident that the 
hooks are well-designed for my purposes? I think Bento's hook concept 
was redesigned 2 or 3 times to make sure it fit well...

>> 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,

And of course, propagating compilation options/configuration, and 
auto-detecting configuration options, is one of the most important parts 
of a complex build. Thus this seem to contradict what you say above.

(Sorry all, I felt like I should answer to a direct challenge. This will 
be my last post in this thread; I've subscribed to distutils-sig.)

Dag