| Summary: | Embedded Python install missing 6 Windows DLL files (LO 7.1.0.3, Python 3.8.4) | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Helio Asteroid <gaxonegaxone> |
| Component: | Installation | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gaxonegaxone, glogow, ming.v.hua |
| Priority: | medium | ||
| Version: | 7.1.0.3 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | 140236 | ||
| Bug Blocks: | |||
|
Description
Helio Asteroid
2021-02-08 21:49:46 UTC
*** Bug 140278 has been marked as a duplicate of this bug. *** It works! LO 7.1.0.3 and Python 3.8.4 Dear Jan-Marek Glogowski, Since you are the author of commit https://git.libreoffice.org/core/+/b4dfba947768834ffecc09056992019878711c8b that upgraded Python to 3.8.4, and the commit log explicitly mentions libffi DLL, I think you may be interested in this one. AFAIK the only missing library is libffi-7.dll (see bug 140236). The rest of them is available either on the system (vcruntime*) or in the program directory (python*.dll, sqlite3.dll). That sqlite3.dll is actually from the NSS build, as LO doesn't build python with sqlite. I don't know how the "missing" list was created, but I guess it was some trial and error. My guess is, that adding the libffi-7.dll is enough and that is already fixed. Can you verify this? Adding libffi-7.dll did resolve my issue. I'm not sure if it's appropriate to mention here, or if you'd prefer separate bug report(s): I find that each time I upgrade LibreOffice (LO), iff LO has embedded a new Python version, then extra python packages I installed (residing in directory "site-packages") over the previous months/years are wiped out, and I must rebuild the environment required by my LO python macros. For that reason, I now religiously check the Release Notes before upgrading LO to see if a new version of Python is included. 1. LO 7.1.0.3 Rel Notes did not (at least, not when I read them) mention the new python version. Could the Rel Notes be updated to help others? 2. Not sure if this is reasonable / advisable, but is it possible for the installation process to automatically preserve the LO user's python package environment in cases where LO is delivering a new python version? 3. If answer to #2 is no, is there any way to at least include pip (or somehow boostrap pip automatically) in the embedded python? That would simplify re-establishing the package environment needed by LO user's python macros. Thanks for resolving the DLL issue. Let me know if one or more of items 1-3 belong in a separate bug report. (In reply to gaxonegaxone from comment #5) > Adding libffi-7.dll did resolve my issue. Ok. I'll close this as a duplicate. > I'm not sure if it's appropriate to mention here, or if you'd prefer > separate bug report(s): I find that each time I upgrade LibreOffice (LO), > iff LO has embedded a new Python version, then extra python packages I > installed (residing in directory "site-packages") over the previous > months/years are wiped out, and I must rebuild the environment required by > my LO python macros. For that reason, I now religiously check the Release > Notes before upgrading LO to see if a new version of Python is included. > 1. LO 7.1.0.3 Rel Notes did not (at least, not when I read them) mention the > new python version. Could the Rel Notes be updated to help others? Adding that info to the release notes is easy enough, if people don't forget it, even that I don't see any benefit. You would see a failure instantly anyway. > 2. Not sure if this is reasonable / advisable, but is it possible for the > installation process to automatically preserve the LO user's python package > environment in cases where LO is delivering a new python version? Probably. The install directory currently contains a version (program/python-core-<version>). We build + ship our own Python for user convenience and because pyuno is a c++ modules, so it would need to be compiled on a users computer. I don't know, how compatible the Python module interface is, so we could optionally use some system Python on Windows too and just ship a precompiled PyUNO version. So maybe that workaround wouldn't actually work. And it makes things much more complicated and error prone in the end. And if we eliminate the version postfix, I'm not sure that would help or produce more problems, if python versions break stuff. Maybe other stuff relies on this directory name too. This all looks like a can of worms and I doubt that currently any dev would invest time into this. You're free to try yourself, or propose some solution. In any way, this should be an extra bug report for further discussion. > 3. If answer to #2 is no, is there any way to at least include pip (or > somehow boostrap pip automatically) in the embedded python? That would > simplify re-establishing the package environment needed by LO user's python > macros. At least the Windows Python installer uses ensurepip to setup pip. I have no idea, if that call is actually enough, or if there is additional stuff missing in LO's Python build. The documentation claims, that everything is already available and just work: https://docs.python.org/3/library/ensurepip.html The msi call is "python -E -s -m ensurepip -U --default-pip", so I assume it works on Windows too, if LO doesn't skip any pip stuff. > Thanks for resolving the DLL issue. You're welcome. > Let me know if one or more of items 1-3 belong in a separate bug report. *** This bug has been marked as a duplicate of bug 140236 *** |