Major problems with Python environment

English
,
#1

Hi guys,

I’m struggling for several days to setup a Python development environment for LibreOffice on Windows. Though basically I’ve resolved all the issues, I wasn’t expecting it was that hard… The most ironically, in order to write scripts in Python, you have to be a C++ developer, or you just fail setting everything up :sweat_smile: So closer to the topic. My aim was to have a basic IDE (Spyder works fine for me), with debugging and code completion. Here are some major problems I’ve faced with:

  1. There is no ensurepip and no venv modules in LO’s Python. Why?
  2. There are also missing some standard modules like sqlite3, which are dependencies for third-party stuff. But while I could just copy ensurepip and venv from another Python distribution, I couldn’t do that for sqlite3, since it has PYD module which is binary incompatible with PYTHON3.DLL from LO. I was able to overcome it with installing pysqlite3 module, and symlinking it to pretend its sqlite3, but it wasn’t simple too, since LO is missing Python headers and most important, import libraries for PYTHON3.DLL (which is just a shim DLL and is incomplete, missing some required exports). I was able to overcome this by recreating necessary python3.lib by hand, using tools from Microsoft SDK and PYTHON310.DLL as a source. Having this done, sqlite3 dependency was resolved and seems working fine.
  3. Another issue is missing pythonw.exe in LO distribution, which is required for Spyder to run. Copying the one from another Python distro of the same version and arch doesn’t work, since it’s not binary compatible. I was able to workaround this with symlinking python.exe to pythonw.exe, but now I have an extra console window showing up when Spyder is run.

So, my wish for LibreOffice for Windows is it’s embedded Python would include all the standard tools and modules it has in standalone setup, including headers and libraries for compiling stuff with pip and MSVC (when no wheel package is available). This should make developing scripts a bit easier on Windows.

Regards,
sag

1 Like
#3

Almost all of you issues would be solved, if you setup your Windows with WSL2 and install there for Example debian 13 Trixie which comes with LO25.2… and python 3.13… ( LO itself is linked to the OS-python-interpreter ) so you will have no issues anymore with missing pip …sqlite3 etcpp.

If you want not to do so:

As IDE i would suggest VS-code, or if you like, try jupyter-notebook
the Frontend runs in any Webbrowser ( !! but locally on your machine !! )
The last one is my favourite for everything with python.

1 Like
#4

What about other modules, venv for example? It is crucial to have it too, since I don’t want to bloat LO’s site-packages obviously. WSL2 is not a solution, I have only 16 gig of RAM and Firefox eats it all :grin: Regrading copying, yes I know, I am a C++ developer and deeply involved with this stuff. For point 3. I need pythonW.exe, not just python.exe. For IDE I tried using QtCreator but unfortunately, code completion is very slow and stops working often. I have also full VS 2019 Prof, but prefer Spyder for Python.

#5

I cannot tell for Windows, but I would guess if pip is included in 25.8 the venv is also available?!

I run a tiny RaspberryPy5 with 8GB RAM ~50 Tabs on Chromium plus 2 Instances of LO and 2 Instances of Jupyter-notebook ( one for native OS the other for an flatpak-LO25.8.… ) all that runs smooth. ( maybe your issues come from the bloatware called Windows?? :wink: )

sorry … dont know the difference.

I thaught thats an »IDE« for Qt, but not for python?

#6

Why do you answer then? I don’t care how good or bad LO behaves on Linux, it is just not an option. I think if LO is shipped on Windows, it must account for platform specifics. And some problems could be avoided if only Python distribution is more complete. It is only a packaging/deploying issue.

It’s primarily for C++, but also supports developing with PySide, thus also supports Python. Maybe I set it up incorrectly, still learning how to do things…

Thanks for answering anyway.

#7

Sorry, you dont explicitly insist on Windows in your first post, so I gave you a hint in which environ it works best! Nothing else.
I tell you also about the alternatives, and ther culprits AFAIK.
Have a good day!

#8

It does. Linux have always a python installed, so this is (usually) used. For Windows this is missing, so LibreOffice brings its own but until 25.8. quite restricted, but sufficient for internal andmacro-use.
.
You will find nowhere the idea to replace a complete python ide for general purpose programming advertisef by LibreOffice/TDF.
Wiki shows how to make the internal python of LO available for external IDE.
.
I use both in parallel…

1 Like
#9

pythonw is a wrapper to call python-apps from Windows withoot opening a console/terminal-Window. Usefoul for apps with gui.

2 Likes
#10

about MSVC

#11

about MSVC

Thanks, I don’t have issues with it. I only wanted to comment, that in order to compile modules that work with embedded LO Python, one needs to have skills to create missing libraries by hand (with dumpbin/lib tools). Simple “pip install something” won’t work.

#12

Just in case you missed this: You can connect to LibreOffice from external programs (including python), when LO is started with --accept. This allows go use any external version of Python, you can put this in a venv (suggestion python version fits the version used in LibreOffice) and obviously this allows to use any IDE. Problem to solve: You need to install python-UNO-bindings.
IMHO this way is also used by Jupyter-Notebooks mentioned above by @karolus
.
Some informations to start you may find in the following thread on stackoverflow:

#15

And this is the main problem on Windows, due to binary incompatibility of embedded Python and externally used Python. There’s lots of libs which depend on Python3.dll, which is not compatible in LO.

#21

Looking at the bug filled itself, if the interest is having support for python applications with full python, maybe it would be necessary to have an external application that offers services to LibreOffice, you’ll need to vendor and package everything yourself.

If your extension is big enough that has a lot of dependencies from external packages. Maybe it would make sense to architect having a lightweight extension that connects to the real beefy app that handles all the work.

This would save you from the sandboxed python that LO holds and that needs to run in many more platforms(not your concern, but LO concern, I think that this one is a security related one).

Maybe splitting the solution in such a way would expand new opportunities to make the extension work for other packages beyond LO.

For sure it involves more work than the initial need depicted, but will not depend on waiting for new LO versions to support what can be accomplished outside it.

I guess it’s understandable that LibreOffice tries to avoid opening too much doors and windows(as security vectors) and maybe it can help to rethink better solutions.

I think that having a virtualenv inside libreoffice might help a lot, in which case, taking a look at APSO could be of use in case your path is to have everything inside LO.

As a final remark, I think that your use case and filling a bug is important to rethink both from core developers and external programmers.

If you are willing to wait at least a year in case LibreOffice core is convinced that your needs are the course path given that this will impact linux distributions and MacOS work, it will give time to architect and implement the solution with a tiny bridge between LibreOffice and the beefy app that fulfills everything.

In either case I’m really positive about that any code or learnings that you can share on whatever you are developing will be useful in case you want to share any of them.

Thanks for opening this conversation.

#22

Why does this matter?
If you use an external Python, JavaScript, Pascal etc. you tell LibreOffice what to do via a port. You don’t call the python of LibreOffice…
.
This is the environment, where it is really useful to start with XSCRIPTCONTEXT and ask for services from there.

#23

Ok, here’s some follow-up. Today I finally completed my project which I started 1.5 months ago, and which was the reason I wrote my initial post. At its final stage, it took me 5 full-time days developing business logic and debugging, not counting earlier experiments and setup woes (described in post #1). Before that, I’ve had no previous experience doing anything for LO, and a little experience with Python in general (however I’m a professional C++ / C# developer for almost two decades, so not a complete novice :slight_smile:).

In essence, the business task was as following: to automate filling a report for tax service, one per each customer contract that I have. This report is kind of revenue confirmation statement, where I should include the details of all payments made by me and to me, along with receipts, invoices, dates and other credentials, and the final revenue arose from completing the contract. The source data for this report exists mostly in CRM, from where it can be queried by REST API.

Earlier I used a Calc document for this with some basic computations and validity checks. So being aware that LO supports macros in Python, it became a natural choice for automation. I chose Python over Basic mostly due to better developer’s experience and a broad range of third party packages (but it’s rather false advantage, see below…). Having completed this task successfully, here’s my insights which I’ve learned and can share:

  1. AI makes the difference. Having Gemini at hand, it accelerated my development to at least 5 times compared to the old way of googling and asking, not mentioning the improved motivation to continue efforts. Ask AI for what you don’t know, the details you don’t understand, or do the tasks you’re too lazy to do it yourself :wink: Although it does hallucinate sometimes (especially for ScriptForge approach), for better documented and established areas it yields 90% correct code (and this was the second reason I switched to UNO).
  2. ScriptForge - I would suggest not wasting time with it, and go with UNO API from the very beginning. While it does offer simplicity, it’s a big trade-off for functionality.
  3. On the other hand, UNO is really steep in learning. Still have to read some theory to understand it completely…
  4. oooscript - avoid any PyPI packages except pure Python ones. It’s a headache to embed anything binary in a Calc doc. While oooscript does basic things, it skips binary/.pyd files, so modules like requests or pywin32 won’t work. I tried other solutions as well, but they’re mostly aimed at packaging a complete Python application, not just a module with dependencies.
  5. Spyder IDE - proved a good choice for scripts. While it still can’t inspect LO objects in its Variable Explorer, there’s a handy workaround via MRI extension (I wrote a function around it, which creates MRI object and shows UI window with the object of interest). Can be installed with pip, is simple and relatively fast. By the way, here’s the script which runs it without pythonw.exe:
@echo off
set PATH=C:\Program Files\LibreOffice\program;%PATH%
call venv\Scripts\activate.bat
start "Spyder" /B python -m spyder.app.start
deactivate
  1. The loader pattern - really needs some basic examples somewhere. It took me hours to determine why XSCRIPTCONTEXT doesn’t travel to the wrapped code…
  2. It appears the only practical way to develop Python macros on Windows is the venv approach I described in post #1. Other distributions won’t work (or I just missed something), since you need to import the UNO module anyway, and it’s DLLs are binary incompatible with any other Python.

Hope this will bring more context and rationale to fixing the issues I filed on LO bug tracker.

#2

Reading Designing & Developing Python Applications - The Document Foundation Wiki may help you figure LO Python infrastructure.

Note that pip is included from release 25.8 onwards.

#13

Ok, I updated LO to 25.8, indeed there’s now ensurepip included. But still no venv and no sqlite3, no _lzma.pyd while lzma.py exists (but it won’t load). I’ve built and embedded Python runtime myself into products of the company I work for, both for Windows and Mac, and I don’t see why that’s a problem to include everything available… If not in the main distribution, but maybe as a separate development package, along with C-headers and libs. One should be able to easily create venv from LO Python, and use development tools of choice as usual. But I see wiki offers docker instead, that’s ridiculous…

#14

To file a bug start here

#16

Done, here it is.

#17

If you consider pandas as important module, then there is an extension: https://extensions.libreoffice.org/en/extensions/show/99231

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