MSI: Remove dependency from win32com.client module

[amaury, 2011-01-31 19:00:16]

Hi,

2011/1/31  <techtonik@gmail.com>:
> Reviewers: ,
>
> Please review this at http://codereview.appspot.com/4080047/
[...]

It looks good, but did you create an item in the issue tracker?

-- 
Amaury Forgeot d'Arc

[Georg, 2011-01-31 19:05:29]

Is there a bugs.python.org issue for this?

[techtonik, 2011-01-31 20:45:44]

There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean
up the code a bit while I am trying to understand how to add Python to the PATH.

I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more
beneficial to development as it doesn't require switching from console to
browser for submitting changes. This way tiny changes can be integrated/updated
more rapidly.

1.
http://mercurial.selenic.com/wiki/ContributingChanges#The_basics:_patches_by_...

[brian.curtin, 2011-01-31 20:49:43]

On Mon, Jan 31, 2011 at 14:45, <techtonik@gmail.com> wrote:

> There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
> to clean up the code a bit while I am trying to understand how to add
> Python to the PATH.
>
> I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
> more beneficial to development as it doesn't require switching from
> console to browser for submitting changes. This way tiny changes can be
> integrated/updated more rapidly.
>
> 1.
>
>
http://mercurial.selenic.com/wiki/ContributingChanges#The_basics:_patches_by_...
>
>
> http://codereview.appspot.com/4080047/


Please create an issue.

[Martin v. Löwis, 2011-02-01 00:05:07]

What's the rationale of this change? It certainly doesn't remove the dependency
from win32com.client (i.e. the code continues to depend on win32com).

[techtonik, 2011-02-01 07:22:57]

It removes the dependency from msi.py making it easier to do the rest in
subsequent patches.

[Martin v. Löwis, 2011-02-01 19:50:23]

On 2011/02/01 07:22:57, techtonik wrote:
> It removes the dependency from msi.py making it easier to do the rest in
> subsequent patches.

What rest specifically? Why are the msilib changes needed for that?

[techtonik, 2011-02-02 07:14:17]

On 2011/02/01 19:50:23, Martin v. Löwis wrote:
> On 2011/02/01 07:22:57, techtonik wrote:
> > It removes the dependency from msi.py making it easier to do the rest in
> > subsequent patches.
> 
> What rest specifically? Why are the msilib changes needed for that?

The rest is to use ctypes, so that no external packages will be required to
build Python installer.

[Martin v. Löwis, 2011-02-02 07:18:33]

On 2011/02/02 07:14:17, techtonik wrote:
> On 2011/02/01 19:50:23, Martin v. Löwis wrote:
> > On 2011/02/01 07:22:57, techtonik wrote:
> > > It removes the dependency from msi.py making it easier to do the rest in
> > > subsequent patches.
> > 
> > What rest specifically? Why are the msilib changes needed for that?
> 
> The rest is to use ctypes, so that no external packages will be required to
> build Python installer.

Ah. That shouldn't be done. If anything is to be done, the builtin msilib can be
considered, instead. Given the choice of using either ctypes or an external
package, I prefer the external package.

[techtonik, 2011-02-02 07:32:02]

On 2011/02/02 07:18:33, Martin v. Löwis wrote:
> Ah. That shouldn't be done. If anything is to be done, the builtin msilib can
be
> considered, instead. Given the choice of using either ctypes or an external
> package, I prefer the external package.

It is a surprise to find builtin msilib. Why isn't it used? Is an incremental
transition to builtin possible?

[Georg, 2011-02-02 07:36:47]

On 2011/02/02 07:32:02, techtonik wrote:

[...]

Can you PLEASE take this off python-dev and move to an issue at
bugs.python.org?  At least remove python-dev from the CC, or we'll
have to temporarily block messages from codereview.

[techtonik, 2011-02-02 08:16:18]

On 2011/02/02 07:36:47, Georg wrote:
> On 2011/02/02 07:32:02, techtonik wrote:
> 
> [...]
> 
> Can you PLEASE take this off python-dev and move to an issue at
> bugs.python.org?  At least remove python-dev from the CC, or we'll
> have to temporarily block messages from codereview.

No need to shout. It is here - http://bugs.python.org/issue11097 CC is removed.

[Martin v. Löwis, 2011-02-02 08:36:45]

> 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).
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 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).

Regards,
Martin

[techtonik, 2011-02-02 11:03:30]

On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. Löwis" <martin@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.