https://bugs.documentfoundation.org/show_bug.cgi?id=163404
--- Comment #7 from [email protected] --- > Your so called »patch« doesnt make a difference…the traceback with original > pythonscript.py: That makes sense. I basically noted that in the code comments of getPackageName2PathMap. Here are the comments. # com.sun.star.deployment.thePackageManagerFactory is deprecated. # # This method works fine when called after LibreOffice is started; # however, it fails when called during the startup of LibreOffice. # # Both ExtensionManager and thePackageManagerFactory have the same issue in this case. # # The error message is: # null process service factory at ./comphelper/source/processfactory/processfactory.cxx:79 # args: (null process service factory at ./comphelper/source/processfactory/processfactory.cxx:79,) # typeName: 'com.sun.star.uno.DeploymentException' # value: null process service factory at ./comphelper/source/processfactory/processfactory.cxx:79 # # see also: https://bugs.documentfoundation.org/show_bug.cgi?id=163404 # This was discover when I was working on "ooo-development-tools" (OooDev). # OooDev can also start LibreOffice via the command line and run a script. # If this script calls PythonScriptProvider(ctx, "share:uno_packages") it will get the error above. # The workaround for OooDev is here: https://github.com/Amourspirit/python_ooo_dev_tools/blob/main/ooodev/uno_helper/py_script/python_script.py # Notably the big difference is that OooDev used it ctx that was created during the startup of LibreOffice. # Example usage is can be seen here: https://github.com/Amourspirit/python_ooo_dev_tools/blob/main/ooodev/uno_helper/importer/importer_shared_script.py # # Summary: # This method works fine when called after LibreOffice is started. # thePackageManagerFactory is deprecated. # ExtensionManager works as expected and is the only really change in this method. So in summary this patch is to replace thePackageManagerFactory (because it is depreciated) with ExtensionManager. I am not sure how to debug the error that you are getting. I don't know if this by design or a bug. Yes, thePackageManagerFactory and ExtensionManager and both work for me in APSO console however do fail when I am starting LibreOffice from the command line. In my verson of getPackageName2PathMap in python_script.py it does work when started from the command line. My extension_manager_comp see here https://github.com/Amourspirit/python_ooo_dev_tools/blob/main/ooodev/adapter/deployment/extension_manager_comp.py The big difference is my code in OooDev loads the singleton from the context that is created when LibreOffice is started from the command line instead of directly from uno.getComponentContext().getValueByName(...). So, maybe there is another bug but currently I do not know how to debug this in libreOffice but there is a need to bring getPackageName2PathMap up to date with ExtensionManager. I know this is not the most clear communication so please ask any question that might help. Here is an example for reference of a simple use case using OooDev that I put together for testing an it works when my version of getPackageName2PathMap is used but fails when I try and use the current version of getPackageName2PathMap from __future__ import annotations from pathlib import Path from ooodev.calc import CalcDoc from ooodev.loader import Lo from ooodev.uno_helper.importer import importer_shared_script from __future__ import annotations from ooodev.calc import CalcDoc from ooodev.loader import Lo from ooodev.uno_helper.importer import importer_shared_script def main(): _ = Lo.load_office(connector=Lo.ConnectPipe()) doc = None try: doc = CalcDoc.create_doc(visible=True) try: with importer_shared_script(): import Capitalise print("Success") except Exception as e: print(f"Error: {e}") except Exception as e: print(f"Error: {e}") finally: if doc: doc.close() Lo.close_office() if __name__ == "__main__": main() -- You are receiving this mail because: You are the assignee for the bug.
