Description: 1. No (simple) way to create virtual environment for embedded Python, using standard approach via "python.exe -m venv venv" command. 2. Missing standard modules and binaries in embedded runtime (sqlite3, _lzma.pyd and others), which makes third party modules installation/operation to fail (for example, included lzma.py won't load on Windows). 3. Missing pythonw.exe binary (note the "W" in the name!) which makes Spyder (and other GUI apps) to fail on startup. 4. Missing import library and headers for python3.dll/python311.dll, which makes it impossible to compile some modules for which prebuilt "wheel" doesn't exist. For example, trying to replace missing sqlite3 with pysqlite3, fails due to missing Python.h (easily fixable) and missing Python3.lib (not so easily fixable). 5. Complications arose from existence of Python3.dll (shim dll, incompatible with official Python3.dll) and Python311.dll (compatible but with a non-standard name). All these issues make developing Python scripts on Windows way more complicated than it could/should be. Steps to Reproduce: 1. Try to run python -m venv venv 2. Try to import lzma in a script 3. Try to install something which depends on sqlite3 (for example Spyder) 4. Try to run Spyder from venv Actual Results: 1. Fails 2. Fails 3. Fails 4. Fails Expected Results: 1. venv is created 2. import lzma doesn't fail 3. pip install spyder doesn't fail 4. Spyder runs Reproducible: Always User Profile Reset: No Additional Info: Developing Python script on Windows is too complicated now, due to difficulties setting up (efficient in regard to time and resources) development environment. Setting up should be as simple as: 1. set PATH=C:\Program Files\LibreOffice\program;%PATH% 2. mkdir project && cd project 3. python -m venv venv 4. venv\Scripts\activate 5. pip install spyder 6. spyder And then start developing scripts, having decent debugger and code inspection/completion.
Workarounds exist for every step in Steps to reproduce, however they require knowledge far beyond necessary to develop Python scrips.
Workarounds for those who interested: 1. Copy venv module from Python distribution of the same version to the "C:\Program Files\LibreOffice\program\python-core-3.11.13\lib" dir. After that, python -m venv venv command should succeed. 2. In order to install pysqlite3 with pip, you should prepare VS environment first. Follow these steps: 2.1 Have MSVS 2019 (any edition) installed 2.2 Download Python source code and copy contents of its Include dir to the Include dir located in the venv 2.3 Now the hard part - recreating Python3.lib: 2.3.1 Open "x64 Native Tools Command Prompt for VS 2019" console 2.3.2 Run command "dumpbin /EXPORTS Python311.dll > Python3.def" 2.3.3 Add these two lines at the beginning: LIBRARY PYTHON3 EXPORTS 2.3.4 Edit/remove everything else so each line contains only a function name, like: PyAIter_Check PyArg_Parse PyArg_ParseTuple ... _Py_write_noraise (total 1632 functions for python311.dll) 2.3.5 Now create import library with this command: lib /DEF:Python3.def /OUT:Python3.lib /MACHINE:X64 2.4 Copy obtained Python3.lib to the virtual environment's venv\libs folder (don't confuse with "Lib"!) 2.5 Activate the venv and run "pip install pysqlite3", it should build the dependencies needed 2.6 Symlink or just copy pysqlite3 as sqlite3 3. If _lzma is necessary, copy _lzma.pyd from an official distribution to the "C:\Program Files\LibreOffice\program" dir. 4. Now run "pip install oooenv ooo-dev-tools types-scriptforge oooscript spyder" 5. Hope it's worked, the last step is to copy python.exe from LO program folder with the name "pythonw.exe" to the venv\Scripts folder 6. Now type "spyder" and it should run NB: I'm writing all these from my memory so I could have missed something...
Removing many modules in the embedded Python is a deliberate choice made by the developers. There is a compile-time option to use the system Python instead of the embedded one, and many Linux distributions chose this option. Though I admit I haven't seen any Windows build doing this, and don't know how viable this approach is on Windows. There are also extensions that installs numpy/scipy or pandas and make them work with LibreOffice. I imagine you can also build an extension that incorporate the parts you mentioned if you choose that approach. In any case, such a blanket report listing multiple issues is unlikely to get any traction. The developers are not going to change their mind and embed full Python into LibO. If you can separate this report into individual issues, some of them may get support (I'm thinking of the pythonw.exe one) and are added to the embedded Python.
> Though I admit I haven't seen any Windows build doing this, and don't know how viable this approach is on Windows. Although there's no "standard" Python on Windows, there are official packages published in the Windows Store from v3.8. But this is only for Win10 and later. > There are also extensions that installs numpy/scipy or pandas and make them work with LibreOffice. I imagine you can also build an extension that incorporate the parts you mentioned if you choose that approach. You can't easily build anything for LO due to reasons I explained in the item #4 in Description. > The developers are not going to change their mind and embed full Python into LibO. There's no such thing as "lite" Python or "full" Python. It either works or is broken. The Python is LO is broken, and I explain why.
(In reply to denis.gz from comment #4) > Although there's no "standard" Python on Windows, there are official > packages published in the Windows Store from v3.8. But this is only for > Win10 and later. Note that LibreOffice has dropped support for anything older than Win10. (In reply to Ming Hua from comment #3) > In any case, such a blanket report listing multiple issues is unlikely to > get any traction. In general, you are correct about the need to have separate reports. Here, we definitely need *additional* reports for individual issues listed here. However, this seems to be a case when having a summary is useful to have a good overview. The strategy may change depending on how easy it is to handle issues one by one vs. making a big change. > The developers are not going to change their mind and embed full Python into > LibO. This is a strange statement. Was there some set-in-stone decision, with a law prohibiting a change of it? (In reply to denis.gz from comment #4) > There's no such thing as "lite" Python or "full" Python. It either works or > is broken. The Python is LO is broken, and I explain why. The Python in LibreOffice is not intended to be necessarily "working" in the sense you put in it; it is *not* the thing you have in mind when you write the word "Python" - it is rather an internal tool, *based on* (but not necessarily providing all functionality of) the original Python, intended to fulfil the goals set by *this* project. It doesn't mean that we can't change it, as our ideas / vision changes; but the "either or" approach is not productive, too.
See also: tdf#127593, tdf#162786 and the longish Depends On and See Also lists there, where you may find some examples of steadily increasing coverage of the bundled set of standard modules.
Some packages not shipped deliberately: https://opengrok.libreoffice.org/xref/core/external/python3/ExternalPackage_python3.mk?r=528cdd6573748d01c9d99ca3710a808866281921#175
> Mike Kaganski 2025-09-18 08:33:48 UTC > Note that LibreOffice has dropped support for anything older than Win10 Great, so maybe using system-provided Python could be an option on Windows too. At least for development. > However, this seems to be a case when having a summary is useful to have a > good overview. The strategy may change depending on how easy it is to handle > issues one by one vs. making a big change. All these issues are related and easily fixable by providing a well-formed Python environment. Regarding pip, there is no need to provide ready-made pip, since this is intended for developers mostly. Only ensurepip is needed. > The Python in LibreOffice is not intended to be necessarily "working" in the > sense you put in it Well, the only sense I put in it, is that it shouldn't fail in legitimate code (see my points for "import lzma" for example). And due to incompatibilities of LO's python3.dll, one can't take missing binaries from official distro either. So LO's Python is definitely broken.
> Xisco Faulí 2025-09-18 08:52:19 UTC > Some packages not shipped deliberately: I could comment: >dbm, sqlite3 - need some database stuff - sqlite3 doesn't need any DB stuff >curses - need curses to build the C module - Yes, but curses is a text UI library, seems to be not much usable in LO macros. >idlelib, tkinter, turtledemo - need Tk to build the C module - Yes, but Tk itself is very old UI lib. If some fancy UI is really needed in a LO macro, there is much better Qt for Python alternative (available as a pyside2 module). >venv - why would we need virtual environments - For macro developments, of course. See the concluding lines of this my comment: https://bugs.documentfoundation.org/show_bug.cgi?id=168215#
(In reply to denis.gz from comment #8) > > The Python in LibreOffice is not intended to be necessarily "working" in the > > sense you put in it > > Well, the only sense I put in it, is that it shouldn't fail in legitimate > code (see my points for "import lzma" for example). Exactly. The 'import lzma' is not necessarily "legitimate code" in LibreOffice's Python.
Regarding lzma, I added it in 892c0d2ef0ee43e079aff51dcc09572d76689ec1 in but it was reverted in 590157ac1584fb829b0c61905298114e7c4adfde
> Mike Kaganski 2025-09-18 09:38:25 UTC > Exactly. The 'import lzma' is not necessarily "legitimate code" in > LibreOffice's Python. Which code is legitimate then? If the only intent is to manipulate internal LO objects, the Basic would be just enough. I thought Python is provided for a user to have more data-mining means, not just self-written solutions. And I can't see why a generic data-compression library can't be supported. The LO developers don't even need to write anything, just include what is already available.
(In reply to denis.gz from comment #12) This is totally off-topic. We should not try to discuss what is and isn't legitimate code here. My point is: do not claim things based on some extreme point of view. The bug you filed should resolve some specific issues. file specific bugs for them, and summarize them here. But not in the form like "either or". And every small thing we put into LibreOffice is a potential security issue. Which the project must monitor and address, even when it's fixed upstream. It's not a zero-cost bonus.
> Mike Kaganski 2025-09-18 09:58:56 UTC > My point is: do not claim things based on some extreme point of view. The bug > you filed should resolve some specific issues. Ok, I'll split it if it helps.
Added specific tickets per each issue reported (linked in See Also).
(In reply to denis.gz from comment #15) > Added specific tickets per each issue reported (linked in See Also). I guess we can closed this one then