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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
