[Distutils] pywin32 on wheels [was: Beyond wheels 1.0: helping downstream, FHS and more]

[Mark Hammond]

As already mentioned in this thread, most of the postinstall stuff is 
needed only for a subset of users - mainly those who want to write COM 
objects or Windows Services (and also people who want the shortcuts etc).

pywin32 itself should be close to "portable" - eg, "setup.py install" 
doesn't run the postinstall script but leaves a largely functioning 
pywin32 install.

So I think it should be relatively easy to achieve for pywin32 to work 
in a virtual env without running any of the post-install scripts, and 
I'd support any consolidation of the setup process to support this effort.

Cheers,

Mark

On 16/04/2015 8:11 PM, Tim Golden wrote:
> [cc-ing Mark H as he indicated he was open to be kept in the loop; also
> changed the title to reflect the shift of conversation]
>
> On 16/04/2015 09:21, Paul Moore wrote:
>> On 16 April 2015 at 08:30, Tim Golden <mail at timgolden.me.uk> wrote:
>>>> Sorry - I agree it's an awful idea. Older wininst installers such as
>>>> the pywin32 (and I think the PyQT one) one do this, I wanted to use it
>>>> as an example of abuse of postinstall scripts that should *not* be
>>>> perpetuated in any new scheme.
>>>
>>> FWIW I've just had a to-and-fro by email with Mark Hammond. I gather
>>> that he's now given Glyph access to the PyPI & hg setup for pywin32.
>>>
>>> He's also happy to consider changes to the setup process to support
>>> wheel/virtualenv/postinstall improvements. There's been a side
>>> discussion on the pywin32 list about which versions of Python pywin32
>>> should continue to support going forward, which obviously interacts with
>>> the idea of making it wheel/virtualenv-friendly.
>>
>> Thanks for involving Mark in this. While pywin32 isn't the only
>> project with a postinstall script, it's one of the most complex that I
>> know of, and a good example to work from when looking at what projects
>> need.
>>
>>> I'm not sure what Glyph's plan is at this point -- doubtless he can
>>> speak for himself. I gather from Paul's comments earlier that he's not a
>>> particular fan of pywin32. If the thing seems to have legs, I'm happy to
>>> coordinate changes to the setup. (I am, technically, a pywin32 committer
>>> although I've never made use of that fact).
>>
>> To be clear, I don't have that much of a problem with pywin32. I don't
>> use it myself, these days, but that's because (a) it's a very big,
>> monolithic dependency, and (b) it's not usable directly with pip. The
>> problem I have with it is that a lot of projects use it for simple
>> access to the Win32 API (uses which can easily be handled by ctypes,
>> possibly with slightly more messy code) and that means that they
>> inherit the pywin32 problems. So I advise against pywin32 because of
>> that, *not* because I think it's a problem itself, when used for
>> situations where there isn't a better alternative.
>>
>>> The particular issue I'm not sure about is: how does Paul see pywin32's
>>> postinstall steps working when they *are* needed, ie when someone wants
>>> to install pywin32 as a wheel and wants the COM registration to happen?
>>> Or is that a question of: run these steps manually once pip's completed?
>>
>> To be honest, for the cases I encounter frequently, these requirements
>> don't come up. So my experience here goes back to the days when I used
>> pywin32 to write COM servers and services, which was quite a while
>> ago.
>>
>>  From what I recall, pywin32 has the following steps in its postinstall:
>>
>> 1. Create start menu entries. My view is that this should simply be
>> dropped. Python packages should never be adding start menu entries.
>> Steve Dower has confirmed he agrees with this view earlier on this
>> thread.
>> 2. Move the pywin32 DLLs to the system directory. I don't see any way
>> this is compatible with per-user or virtualenv installs, so I don't
>> know how to address this, other than again dropping the step. I've no
>> idea why this is necessary, or precisely which parts of pywin32
>> require it (I've a recollection from a long time ago that "services
>> written in Python" was the explanation, but that's all I know). But
>> presumably such use cases already break with a per-user Python
>> install?
>> 3. Registering the ActiveX COM DLLs. I believe this is mostly obsolete
>> technology these days (who still uses ActiveX Scripting in anything
>> other than VBScript or maybe a bit of JScript?) I'd drop this and make
>> it a step that the user has to do manually if they want it. In place
>> of it, pywin32 could provide an entry point to register the DLLs
>> ("python -m pywin32 --register-dlls" or something). Presumably users
>> who need it would understand the implications, and how to avoid
>> registering multiple environments or forgetting to unregister before
>> dropping an environment, etc. That sort of pitfall isn't something
>> Python should try to solve automatically via pre- and post- install
>> scripts.
>> 4. Registering help files. I never understood how that worked or why
>> it was needed. So again, I'd say just drop it.
>
> Really, pywin32 is several things: a set of libraries (win32api,
> win32file, etc.); some system-level support for various things (COM
> registration, Service support etc.); and a development/editing
> environment (pythonwin).
>
> I see this ending up as (respectively): as venv-friendly wheel; a py -m
> script of the kind Paul suggests; and an installable app with the usual
> start menu icons etc.
>
> In my copious spare time I'll at least try to visit the pywin32 codebase
> to see how viable all this is. Feel free to challenge my thoughts on the
> matter.
>
>
> TJG
>