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

[Daniel Holth]

This seems like a good time to remind everyone that "wheel convert"
can turn bdist_wininst .exe's to wheels. Both formats are designed to
preserve all the distutils file categories. In the future it would be
nice if the bdist_wininst .exe wrapper used wheel instead of its own
format. Then a single file would both be the Windows installer and a
valid wheel (except for the extension).

On Thu, Apr 16, 2015 at 9:43 AM, Kevin Horn <kevin.horn at gmail.com> wrote:
> 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
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>