[Distutils] PEP 345, PEP 376, PEP 386

[Paul Moore]

2009/6/4 Tarek Ziadé <ziade.tarek at gmail.com>:
> On Thu, Jun 4, 2009 at 3:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> Also, you need to remember that bdist_wininst is not a "third-party"
>> tool. It's part of distutils (although it's probably written in such a
>> way that it could easily be extracted as a 3rd party addin - I
>> honestly don't know).
>
> I think that would be great to externalize such command to decouple
> its release cycles
> from Python (As mentioned during the Langage summit)
>
> The only requirement would be to find someone that would lead its development,
>
> If I find a windows developer that wants to handle this  <hint> <hint>
> , we could probably
> create a separate project

Not a chance :-) No way do I have sufficient time, I'm afraid. And
personally, I prefer it built in, so I'm ideologically opposed to the
idea as well :-)

But I'm happy to offer advice and information to anyone who needs to
know more about the way the Windows system works.

>> I'd seriously recommend looking at bdist_wininst as an example - it's
>> distributed with Python, so the source is easy to find, but it
>> installs extra system-level metadata above and beyond what setup.py
>> install does, so you can see what sorts of issues you have to deal
>> with. (Some of the Unix-level packagers like bdist_rpm may be equally
>> illuminating, but I've no experience with those).
>
> I will, thanks for the tip. I guess bdist_msi should be also our
> target for this,

Yes, but bdist_wininst is likely to be a *lot* easier to follow,
because (as far as I understand it) bdist_msi builds a blob of
structured binary data (it's essentially a custom form of database
packed in one file) which is read and parsed by the Windows installer
service. So a lot of the mechanisms are hidden, compared to
bdist_wininst which is a "roll your own" approach to setting up the
required metadata.

Paul.