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. Have I missed anything else? Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig