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

[Kevin Horn]

Tim,

As a long time user, I think you're right on the money.

My only concern is how to manage the transition in user experience, as
moving to what you've described (which I totally approve of, if it's
feasible) will be a significant change, and may break user expectations.

I think maybe the best thing to do is to change the existing binary
installer package to:
- install the included wheel in the system python environment
- run the various post-install scripts (py -m)
- install pythonwin, along with start menu icons, etc.

Those that want to use pywin32 in a virtualenv (or just without all the
system changes) could simply install the wheel (or even an sdist, perhaps)
from the command line using pip, and then perform whatever other steps they
want manually.

This would allow those who are installing using the installer package
(which I assume is almost everybody, right?) to get a similar experience to
the current one, while those wanting more control (use in virtualenvs, etc)
to have that as well.

I think the changes described have the potential to be a big win.


On Thu, Apr 16, 2015 at 5:11 AM, Tim Golden <mail at timgolden.me.uk> 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
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
--
Kevin Horn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150416/d7fce02c/attachment-0001.html>