[Libreoffice-bugs] [Bug 140279] Embedded Python install missing 6 Windows DLL files (LO 7.1.0.3, Python 3.8.4)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=140279

Jan-Marek Glogowski <glogow at fbihome.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Jan-Marek Glogowski <glogow at fbihome.de> ---
(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 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210219/a4574033/attachment-0001.htm>