On 16 April 2015 at 08:30, Tim Golden <m...@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.
