Major problems with Python environment

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

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

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.

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?

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.

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!

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

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

2 Likes

about MSVC

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.

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:

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.

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.

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.

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.

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…

To file a bug start here

Done, here it is.

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

Thanks, but I only meant standard Python modules, which are absent/don’t work.