On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > >> It is a surprise to find builtin msilib. Why isn't it used? > > Originally, because Python needs to be packaged with an older > release (in particular one that isn't itself maintained anymore).
That doesn't answer the question why Python could not be packaged with a newer release of 'msilib' at that time? > Today, the problem is that the msilib package doesn't support > merge modules (and if such support was added, we would have to > wait until the version containing it isn't maintained anymore). I don't understand the phrase in (). What for do we need to wait after adding support for merge modules to builtin msilib? I imagine we've added support for merge modules to msilib, and then waiting until new msilib version with merge support isn't maintained anymore. And only then we can use it to create installer. Sounds like a nonsense. Anyways, is it possible to reuse builtin msilib to the max and add required 'merge modules' functionality inside msi.py or extension module? > I don't consider the dependency on win32com a serious issue at > all; it's just a mild annoyance (much less than reliance on ctypes > would be, or hard-coding of symbolic constants). There is nothing wrong with hardcoded symbolic constants - Microsoft specifically provides values for them in their MSDN materials to be used with scripting languages which doesn't have include files. They just need to be validated one time, and won't change in future. Why don't you like ctypes solution? I find it strange that Python build process avoids using its own modules. -- anatoly t. _______________________________________________ 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