toggle quoted messageShow quoted text
Don't mean to hijack, but if the infrastructure and who has
access is not addressed sooner than later updating anything bar
manual is going to be a problem but I am sure you are allready
aware of this so I will stop.
On 31/01/2021 8:37 pm, Joseph Lee
I understand that. I wrote my earlier
response both as an add-ons community member and as the
administrator of this list. In short, let’s not hijack a
thread to talking about something completely different –
add-on update facility is not the same thing as preparing
add-ons to support Python 3.8. Besides, it will take days to
weeks to prepare NVDA to support Python 3.8, so add-ons
community have some time to learn more about Python 3.8
incompatibilities and prepare accordingly (I say “days to
weeks” as moving from Python 3.7 to 3.8 is easier than 2.7
There is sort of a related issue –
eventual end of support for Windows 7 and Server 2008 R2
from NVDA, but that’s a separate thread for another time.
For now, for people wanting to it, let’s give folks a chance
to learn Python 3.8.
Fine, but what I am trying to say is before we even try to
update our addons a stable infrastructure would be a good
Right now its well everyone knows how it is.
Right now there are some access issues to those that need it
and some stuff is up in the air.
We really can't make stable updates if users have to manually
update them, I mean I guess we could if we had to but it would
be nice to sort out at least to get things back to where they
were or if so better is all.
On 31/01/2021 7:54 pm, Joseph Lee wrote:
That’s something else (let’s not
discuss Add-on Updater issues in this thread please as it
is a different topic altogether).
Well, before we even decide on that we need to figure all
the issues with addons access, the fact addon update can't
automatically update its list of addons whenever a new one
or new update is added etc.
On 31/01/2021 5:12 pm, Joseph Lee
Hello NVDA add-ons community,
The following should be considered
a major advisory and should be applied as soon as
possible (this isn’t a critical advisory where you
need to take immediate action):
A few days ago Reef Turner from NV
Access announced that upcoming NVDA version (2021.1)
is targeting Python 3.8. Based on initial tests with
Project Walrus builds sent out last year, moving NVDA
from Python 3.7 to 3.8 is a bit easier than 2019 when
we moved from Python 2 to 3 (NVDA 2019.3; you may
recall all sorts of discussions about it then).
However, there are some gotchas you need to be aware
of, and I advise applying changes marked as “required”
as soon as possible in order to minimize disruptions
caused by add-on unavailability:
- Python C extensions
(required if using pyd files): if your add-on uses
Python modules with C extensions (.pyd files), you
MUST use C extensions designed for Python 3.8. If
you need to support NVDA 2019.3 and 2020.x alongside
2021.1, you must include both Python 3.7 and 3.8 pyd
files because Python 3.8 will not load Python 3.7 C
extensions. The most prominent add-on affected is
Resource Monitor (not anymore; see notes).
(required): if you are creating threads through
threading.Thread and wish to check if a thread is
alive, you must now use threading.Thread.is_alive
instead of threading.Thread.isAlive. This affects
several add-ons, including StationPlaylist (see
- Resource Monitor: no
action required – in fact, it is the first add-on to
support Python 3.8 and 3.9 (C extensions for 3.7,
3.8, and 3.9 for Psutil are included with this
- StationPlaylist: no
action required – mitigations in place since early
- The above porting notes
can change if NVDA ships with newer dependencies
such as wxPython.
Just like we did with NVDA 2019.3,
I advise add-on authors to publish their add-ons’
readiness for NVDA 2021.1 once 2021.1 beta 1 is