Python / NumPy in LibreOffice

Board Discuss
#1

Dear TDF Board,

I’ve been working (with others) on an extension WriterAgent that started off with AI features for Writer, and then I realized that adding Python / NumPy would be very useful. It now has a bunch of functionality that I believe should have been included in the core LibreOffice product years ago.

The Python ecosystem gives easy access to powerful capabilities such as for data analysis, vector and full-text search, and OCR, which I’ve implemented initial versions of in the plugin. The Python ecosystem is so large it’s mind-blowing, and it’s all just one “uv/pip install” away. The code isn’t all written in Python of course, but the install process plus the bundled wrappers make it seem that way.

Microsoft added Python to Excel in 2024, so it should be added for competitive reasons as well as it being a great idea: Python is the most popular programming language, suitable for children to data scientists. However, the MS design is bad with an xl() function that breaks recalc, and they currently require you to run NumPy in the cloud and charge for it, they don’t support running it locally.

The plugin is a mix of AI and Python features which we could separate. For now having it unified is simplest because we evolve the features, and how they are exposed to the user and LLMs at the same time. The main dev design document is here.

I’m writing because I’ve sent multiple emails over multiple weeks to the libreoffice-dev alias and heard nothing back regarding the =Python() design, or code. My questions for the board are:

  1. Does this align with LibreOffice’s roadmap?
  2. Would TDF support upstreaming this as a core feature or official extension?
  3. If there are no longer experienced Calc developers willing to give feedback on complicated features like this, how is the Board addressing this lack of engineering oversight?

Thank you,

-Keith

#2

=Python("") in Calc, TeX import

#3

A few meta-points:

  • The Board of Directors manages the TDF; it does not decide technical matters. We don’t actually have a clear decision making process on technical policy, and our “Engineering Steering Committee” has stated that it doesn’t actually steer… still, it’s the ESC you should address, I believe.
  • We have recently hired a developer focused on support for scripting: Neil Roberts, @bpeel , who may also want to chime in.
  • For such a contribution to be considered, it has to - in my humble opinion as a TDF trustee and not as a developer or officer - strip all “AI” functionality, and any code which tracks user activity and “calls home” with user data.

This is all without judging the technical merit of the project - something I am not qualified to do (I lack the relevant experience). Generally, I would of course like it if more of the Python ecosystem was more easily accessible to LO script authors.

1 Like
#4

Thank you for the helpful context. It’s great to know Neil Roberts is on board looking at scripting, and I’d love to get feedback on the architecture.

To clear up the point regarding AI and privacy: the extension runs locally. There is zero tracking or data collection, and it does not call home regarding anything the user does. The focus is on local, open-weight models running on the user’s machine.

However, I understand the sensitivity around AI, my proposal isn’t regarding those features. I am open to stripping out the AI code and focusing strictly on =PY(), the cross-process NumPy execution engine, NumPy-based analysis tools, OCR, rich-text editor, etc.

If I strip it out, I’d have to figure out where the config parameters are saved, where the settings UI and menu items go, etc. I’m willing to do the work, but I need to see feedback and encouragement first.

I will reach out to the ESC and Neil and ask for advice.

Thanks!

-Keith

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.