search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 638 forks source link

Provide a way for add-ons to specify python pip package dependencies #17408

Closed mltony closed 6 days ago

mltony commented 1 week ago

Is your feature request related to a problem? Please describe.

Often times add-on developers would like to make use of some python pip packages. However, currently this is not possible. Over the years I have seen add-on authors develop various ways to work around this problem.

Describe the solution you'd like

I would like to be able to specify python module dependencies in add-on manifest. I would like NVDA to be able to automatically satisfy these dependencies when installing an add-on. That is I would like NVDA to download required packages and their dependencies recursively and include them into python classPath.

Describe alternatives you've considered

Do nothing. Add-on authors would have to come up with ugly and potentially error-prone workarounds. Extra cost of developing add-ons that depend on non-standard python packages.

Additional context

  1. I recently saw that @cartertemm implemented this in https://github.com/cartertemm/AI-content-describer/ - so his solution may serve as a working prototype. This add-on has several python package dependencies and can automatically download/upgrade them.
  2. It would also be great to have dependencies among NVDA add-ons. For example, my IndentNav add-on provides a better textInfo implementation for VSCode, and in my other add-ons I would like to use that better implementation.
  3. A few examples of packages I wish I could make use of in my own add-ons:
    • winsdk pip package to be able to access and edit clipboard history.
    • pymp3 - to be able to interact with mp3 files and not having to convert all the sounds into wav.
    • threadpool- I had to implement my own threadpool a few times since I couldn't include threadpool package.
    • namedpipe - IndentNav uses named pipes to communicate with VSCode to provide a better TextInfo implementation. I had to rewrite named pipe logic in low level, because I couldn't import the package.
seanbudd commented 6 days ago

Closing as won't accept. This is beyond what the add-on system can support, and we don't want a situation where we are managing different and conflicting packages. We can bundle popular pip libraries with NVDA, if there are any libraries used by a majority of add-ons. Alternatively consider a shared community submodule where dependency management is centralized?