[Python-Dev] Status of packaging in 3.3 (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Sat Jun 23 14:27:52 CEST 2012

Dag Sverre Seljebotn <d.s.seljebotn 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

More information about the Python-Dev mailing list