No longer require pyWin32 #9639

michaelDCurran · 2019-05-29T21:00:25Z

Link to issue number:

None.

Summary of the issue:

Since 2006 NVDA has relied on the pyWin32 package for particular things such as some Windows constants, certain COM interfaces, and clipboard functionality.
However, over the years we have replaced much of the code that relies on pyWin32, except for a small particular code paths.

Description of how this pull request fixes the issue:

this pr totally removes the requirement for pyWin32 by doing the following:

hardcodes any constants we were still fetching from win32con, removing the dependency on this module.
Directly implements get and set clipboard data functionality, removing the dependency on the win32clipboard module.
Directly implements code for richEdit that fetches a text representation of an embedded OLE object, removing the dependency on the pythoncom module.

Testing performed:

navigated an older-style richedit document (classic Wordpad) with an embedded Excel object: NVDA could successfully get the text representation on the object.
With the PythonConsole, imported api, and ran copyToClip and getClipData functions multiple times to ensure that NVDA can successfully get and set clipboard data.

Known issues with pull request:

None.

Change log entry:

changes for developers:

The pyWin32 Python package is no longer included with NVDA.

… win32con.

feerrenrut · 2019-05-30T09:04:50Z

I think add-on developers currently rely on our inclusion of pyWin32, also we have an updated dependency ready to go: nvaccess/pywin32-bin#1

We may still want to remove pyWin32, but we should talk about what this will mean for add-on authors first, as well as consider other risks.

beqabeqa473 · 2019-05-30T09:43:08Z

hello most things could be rewritten using ctypes and corresponding libs, so i don't think there could be too much to worry.

…

On 5/30/19, Reef Turner ***@***.***> wrote: I think add-on developers currently rely on our inclusion of pyWin32, also we have an updated dependency ready to go: nvaccess/pywin32-bin#1 We may still want to remove pyWin32, but we should talk about what this will mean for add-on authors first, as well as consider other risks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #9639 (comment)

-- with best regards beqa

nvdaHelper/local/oleUtils.cpp

source/NVDAObjects/window/edit.py

source/api.py

LeonarddeR · 2019-05-30T10:08:05Z

source/winKernel.py

+
+GMEM_MOVEABLE=2
+
+class HGLOBAL(HANDLE):


Could you add a short descriptive doc string here?

source/winUser.py

LeonarddeR · 2019-05-30T10:17:15Z

source/winUser.py

+		# But make sure not to free the memory accidentally -- it is not ours
+		h=winKernel.HGLOBAL(h,autoFree=False)
+		with h.lock() as addr:
+			if addr:


What happens if not addr?

source/winUser.py

LeonarddeR · 2019-05-30T10:24:54Z

I think that most add-ons that utilize pywin32 use win32con. There is also an explicit requirement in setup.py to include win32api, see #7642.

If we decide to keep win32con and win32api, I'm fine with that. I really like getting rid of win32com, though.

source/winUser.py

LeonarddeR · 2019-05-31T06:28:15Z

It looks like this failed building because PyGetWindow did not install properly for system tests.

michaelDCurran · 2019-05-31T09:54:51Z

Since we are breaking all add-ons anyway, and there are easy ways to replace win32api now with ctypes, I don't see the need for keeping pyWin32 modules as a dependency for the sake of add-on developers. However, if the consensus is to keep them for add-ons, I still feel that we should stop relying on them in NVDA core. Mixing comtypes and pythoncom is very confusing, similarly ctypes. And surely one less dependency is always a good thing, when it comes to security updates etc.

LeonarddeR · 2019-05-31T10:50:40Z

@michaelDCurran commented on 31 May 2019, 11:54 CEST:

Since we are breaking all add-ons anyway, and there are easy ways to
replace win32api now with ctypes, I don't see the need for keeping
pyWin32 modules as a dependency for the sake of add-on developers.

Agreed

However, if the consensus is to keep them for add-ons...

We could consider keeping win32con, but it feels slightly weird to keep a file with constants only for the sake of add-ons. Furthermore, add-ons can easily bundle it themselves.

michaelDCurran · 2019-06-03T00:48:29Z

@LeonarddeR Are there any pending review actions from you I need to address?

LeonarddeR

Could you remove the reference to win32api from setup.py as well? AFter that, feel free to merge

… new.

Brian1Gaff · 2019-06-03T19:39:02Z

Ah that has trashed focus highlight version 6 then This taken from the threshold snap. ERROR - globalPluginHandler.listPlugins (20:12:35.267): Error importing global plugin focusHighlight Traceback (most recent call last): File "globalPluginHandler.pyc", line 22, in listPlugins File "C:\nvda test folder\userConfig\addons\focusHighlight\globalPlugins\focusHighlight.py", line 30, in <module> ImportError: No module named win32con DEBUG - core.main (20:12:35.286): Brian bglists@blueyonder.co.uk Sent via blueyonder. Please address personal E-mail to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users -----

LeonarddeR · 2019-06-03T19:53:00Z

This is expected, add-ons need to be updated.

Brian1Gaff · 2019-06-04T07:58:45Z

Viewing the moves of add on writers to update many that are used widely, I think anything that can ease the work a bit and not upset users when the new version appears is perhaps a good thing here, Also do any of the legacy app modules use it that might break things? It seems a lot of add on authors are rather too busy now to update their add ons and I wonder how many have the ability or inclination to update somebody elses code fast enough? Just thinking aloud. Brian bglists@blueyonder.co.uk Sent via blueyonder. Please address personal E-mail to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users -----

Brian1Gaff · 2019-06-04T08:00:22Z

In a perfect world yes, but this is not one of those. Brian bglists@blueyonder.co.uk Sent via blueyonder. Please address personal E-mail to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users ----- Original Message ----- From: "Leonard de Ruijter" <notifications@github.com> To: "nvaccess/nvda" <nvda@noreply.github.com> Cc: "Brian Gaff" <bglists@blueyonder.co.uk>; "Comment" <comment@noreply.github.com>

…

Sent: Monday, June 03, 2019 8:53 PM Subject: Re: [nvaccess/nvda] No longer require pyWin32 (#9639) This is expected, add-ons need to be updated. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #9639 (comment)

LeonarddeR · 2019-06-04T08:15:45Z

This pull request is closed, and I don't think this is the right place to discuss implications for add-on authors. Please use the development list for this if you really think it is necessary that this should be reconsidered.

Again, authors will have to update their add-ons in any case, with or without this change.

By performing pip freeze in the NVDA virtual environment, it appears we no longer use or depend on the library pywin32 - #9639 Pywin32 also has changed licence to the Python Software Foundation licence which is also included in our license file. Therefore, we should remove this custom license from our licence.

By performing pip freeze in the NVDA virtual environment, it appears we no longer use or depend on the library pywin32 - nvaccess#9639 Pywin32 also has changed licence to the Python Software Foundation licence which is also included in our license file. Therefore, we should remove this custom license from our licence.

Remove dependency on pyWin32, including pythoncom, win32clipboard and…

c94d49a

… win32con.

michaelDCurran requested review from LeonarddeR and feerrenrut May 29, 2019 21:00

nvdaHelperLocal's oleUtils.cpp: fix syntax error.

009f31b

LeonarddeR suggested changes May 30, 2019

View reviewed changes

LeonarddeR mentioned this pull request May 30, 2019

Update dependencies for Python 3 #9630

Merged

Address review comments.

c4569d6

michaelDCurran commented May 31, 2019

View reviewed changes

source/winUser.py Show resolved Hide resolved

michaelDCurran force-pushed the noPyWin32 branch from a78c4a4 to c4569d6 Compare May 31, 2019 05:29

LeonarddeR approved these changes Jun 3, 2019

View reviewed changes

michaelDCurran added 2 commits June 3, 2019 15:18

Merge branch 'threshold' into noPyWin32

12da054

No longer forceably include win32api via setup.py. Also update what's…

ee38605

… new.

michaelDCurran merged commit ef3ed13 into threshold Jun 3, 2019

nvaccessAuto added this to the 2019.3 milestone Jun 3, 2019

josephsl mentioned this pull request Jul 23, 2019

What's new and readme: we are moving to Python 3.7 #9942

Merged

seanbudd mentioned this pull request Dec 27, 2023

Remove defunct pywin32 license #15970

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No longer require pyWin32 #9639

No longer require pyWin32 #9639

michaelDCurran commented May 29, 2019

feerrenrut commented May 30, 2019

beqabeqa473 commented May 30, 2019 via email

LeonarddeR May 30, 2019

LeonarddeR May 30, 2019

LeonarddeR commented May 30, 2019

LeonarddeR commented May 31, 2019

michaelDCurran commented May 31, 2019 via email

LeonarddeR commented May 31, 2019

michaelDCurran commented Jun 3, 2019

LeonarddeR left a comment

Brian1Gaff commented Jun 3, 2019 via email

LeonarddeR commented Jun 3, 2019 via email

Brian1Gaff commented Jun 4, 2019 via email

Brian1Gaff commented Jun 4, 2019 via email

LeonarddeR commented Jun 4, 2019


		GMEM_MOVEABLE=2

		class HGLOBAL(HANDLE):

No longer require pyWin32 #9639

No longer require pyWin32 #9639

Conversation

michaelDCurran commented May 29, 2019

Link to issue number:

Summary of the issue:

Description of how this pull request fixes the issue:

Testing performed:

Known issues with pull request:

Change log entry:

feerrenrut commented May 30, 2019

beqabeqa473 commented May 30, 2019 via email

LeonarddeR May 30, 2019

Choose a reason for hiding this comment

LeonarddeR May 30, 2019

Choose a reason for hiding this comment

LeonarddeR commented May 30, 2019

LeonarddeR commented May 31, 2019

michaelDCurran commented May 31, 2019 via email

LeonarddeR commented May 31, 2019

michaelDCurran commented Jun 3, 2019

LeonarddeR left a comment

Choose a reason for hiding this comment

Brian1Gaff commented Jun 3, 2019 via email

LeonarddeR commented Jun 3, 2019 via email

Brian1Gaff commented Jun 4, 2019 via email

Brian1Gaff commented Jun 4, 2019 via email

LeonarddeR commented Jun 4, 2019