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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 - [email protected] >> https://mail.python.org/mailman/listinfo/distutils-sig > > > > > -- > -- > Kevin Horn > > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig > _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
