OpenLP-git commit 28 dec wont open.

VikingWithWings

I'm on Arch and have been running OpenLP with most latest commits fine, but after this one today OpenLP won't start. Hopefully this can help to give me a clue on whats wrong. (installed with yay from AUR)

Traceback (most recent call last):

 File "/usr/bin/openlp", line 33, in <module>

  sys.exit(load_entry_point('OpenLP==2.9.5.dev79+13afff24f', 'gui_scripts', 'openlp')())

 File "/usr/lib/python3.10/site-packages/openlp/__main__.py", line 75, in start

  main()

 File "/usr/lib/python3.10/site-packages/openlp/core/app.py", line 452, in main

  set_up_web_engine_cache(portable_path / 'Other' / 'web_cache')

UnboundLocalError: local variable 'portable_path' referenced before assignment

Edit: Seems to bee fixed as of 29. dec. Thank You.

raoul

I would recommend running releases rather than the latest git commit, unless you like pain and suffering ;-) haha

rimach

But for any reason it seems the OpenLP package in PyPI does not include this bugfix. So it was released before?

What is currently the proposed way to install OpenLP in (k)ubuntu?

in: https://packages.ubuntu.com/search?keywords=openlp&searchon=names&suite=kinetic&section=all

Paket openlp

• kinetic (22.10) (x11): Church lyrics projection application [universe]
• 2.9.5-1: all

So the release version not yet arrived.

In https://pypi.org/project/OpenLP/

There is still version from 29.12. /00:09 with the bug above

The https://launchpad.net/~openlp-core/+archive/ubuntu/release

Does have a very old version only.

So what is your recommendation for future Raoul?

apt-get install openlp (wait until package arrive in ubuntu package list)

pip3 install OpenLP (does this is the same installation as via apt?)

raoul

I would wait until the updated version of OpenLP appears in the Debian unstable repository. We don't directly upload to Ubuntu, we let Ubuntu pull OpenLP from Debian.

rimach

Thanks for your answer. What about the last question. Is using pip3 also a possibility to install OpenLP or do you not recommend it?

raoul

The current version of OpenLP in PyPI is actually the wrong git commit (we re-tagged after finding an issue, but PyPI doesn't allow you to re-release an existing version). You can try to pip install from our GitLab repository though, like this, using a virtual environment:

python3 -m venv openlp-env
./openlp-env/bin/pip install git+https://gitlab.com/openlp/openlp@3.0.0
./openlp-env/bin/openlp

This will create a virtual environment so that you don't install things system-wide, and then install OpenLP 3 from git into the virtual environment. You can then run OpenLP by running the openlp binary in the bin directory of the virtual environment.

This is not something I recommend for most users, though.

rimach

Thanks @raoul for your answer. I saw that already that the bugfix for the "portable issue" was not included at PyPI, but I wasn't aware about this re-release limitation of PyPI.

I fixed this by paching the installation of official PyPI version directly.

In general for me it seems to me that releasing to PyPI is much more faster than via official debian package, right?

As far as I can see there are two differences only.

• the PyPI installation doesn't care about VLC
• the translation files are not packaged currently within PyPI package

For the first bullet point I do not have an idea how to solve easily, but probably most user are able to install vlc separately.

The second bullet point seems to be possible. We would only need to create the translation files (*.qm) and add them as part of PyPI package. There is only one issue currently that the folder structure is slightly different. (currently there is no resource/i18n folder in the package at all and additionally the PyPI installation does have one less level. So currently the resource/i18n folder needs to be located in the site-packages folder of the python installation (not good ;-)) or the search function for translation needs to be enhanced to search also directly in openlp folder to find files in PyPI installation.

@raoul what do you think about this?

raoul

@rimach yes, I think the build process for the wheel needs to include building the translation files, and then OpenLP just needs to search in the right place for them. I don't have a problem including the i18n files in the wheel, and therefore in site-packages, I think that makes sense.

rimach

@raoul I would try to step into this topic if anyone else already started.

Is there already a script for the build process for the wheel? (at least in the scripts path I didn't found)

raoul

@rimach You're welcome to try!

It is in our CI configuration: https://gitlab.com/openlp/openlp/-/blob/master/.gitlab-ci.yml#L73

And here is how the translations are built for macOS and Windows: https://gitlab.com/openlp/packaging/-/blob/master/builders/builder.py#L500

It can probably be extracted into a separate script.