Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1762)

Issue 4080047: MSI: Remove dependency from win32com.client module

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 4 months ago by techtonik
Modified:
8 years, 4 months ago
Base URL:
http://svn.python.org/projects/python/branches/release27-maint/
Visibility:
Public.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+20 lines, -13 lines) Patch
M Tools/msi/msi.py View 2 chunks +1 line, -2 lines 0 comments Download
M Tools/msi/msilib.py View 9 chunks +19 lines, -11 lines 0 comments Download

Messages

Total messages: 15
techtonik
8 years, 4 months ago (2011-01-31 18:19:44 UTC) #1
amaury
Hi, 2011/1/31 <techtonik@gmail.com>: > Reviewers: , > > Please review this at http://codereview.appspot.com/4080047/ [...] It ...
8 years, 4 months ago (2011-01-31 19:00:16 UTC) #2
Georg
Is there a bugs.python.org issue for this?
8 years, 4 months ago (2011-01-31 19:05:29 UTC) #3
techtonik
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch ...
8 years, 4 months ago (2011-01-31 20:45:44 UTC) #4
brian.curtin
On Mon, Jan 31, 2011 at 14:45, <techtonik@gmail.com> wrote: > There is no b.p.o issue ...
8 years, 4 months ago (2011-01-31 20:49:43 UTC) #5
Martin v. Löwis
What's the rationale of this change? It certainly doesn't remove the dependency from win32com.client (i.e. ...
8 years, 4 months ago (2011-02-01 00:05:07 UTC) #6
techtonik
It removes the dependency from msi.py making it easier to do the rest in subsequent ...
8 years, 4 months ago (2011-02-01 07:22:57 UTC) #7
Martin v. Löwis
On 2011/02/01 07:22:57, techtonik wrote: > It removes the dependency from msi.py making it easier ...
8 years, 4 months ago (2011-02-01 19:50:23 UTC) #8
techtonik
On 2011/02/01 19:50:23, Martin v. Löwis wrote: > On 2011/02/01 07:22:57, techtonik wrote: > > ...
8 years, 4 months ago (2011-02-02 07:14:17 UTC) #9
Martin v. Löwis
On 2011/02/02 07:14:17, techtonik wrote: > On 2011/02/01 19:50:23, Martin v. Löwis wrote: > > ...
8 years, 4 months ago (2011-02-02 07:18:33 UTC) #10
techtonik
On 2011/02/02 07:18:33, Martin v. Löwis wrote: > Ah. That shouldn't be done. If anything ...
8 years, 4 months ago (2011-02-02 07:32:02 UTC) #11
Georg
On 2011/02/02 07:32:02, techtonik wrote: [...] Can you PLEASE take this off python-dev and move ...
8 years, 4 months ago (2011-02-02 07:36:47 UTC) #12
techtonik
On 2011/02/02 07:36:47, Georg wrote: > On 2011/02/02 07:32:02, techtonik wrote: > > [...] > ...
8 years, 4 months ago (2011-02-02 08:16:18 UTC) #13
Martin v. Löwis
> It is a surprise to find builtin msilib. Why isn't it used? Originally, because ...
8 years, 4 months ago (2011-02-02 08:36:45 UTC) #14
techtonik
8 years, 4 months ago (2011-02-02 11:03:30 UTC) #15
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.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b