update to panel==1.4.4

[blakerosenthal]

I could not find any visible side-by-side differences between panel 1.4.2 and 1.4.4. The file selector popup feels noticeably faster in 1.4.4 though! I did find a couple quirky UI issues that are ragna problems, not panel problems, and I will open separate issues for these.

Closes #451

[blakerosenthal]

@pmeier Am I supposed to update requirements-docker.toml manually or let CI do it? I tried both ways and it's angry either way.

[arjxn-py]

Hi @blakerosenthal, apparantly if you run locally -

pip-compile --quiet --strip-extras --output-file=requirements-docker.lock --extra=all pyproject.toml

It should do it, but I wouldn't recommend that because of the difference in environments on CI & locally.

Until now docker-requirements / update (pull_request) job is just testing if current requirements-docker.lock matches the output of the above command and instead of updating it automatically for you it fails. Because the workflow is supposed to open a separate PR & only if it's manually triggered.

I did some workaround for that in arjxn-py/ragna#3 (See b60ca7a is auto-generated), please have a look.

[pmeier]

It should do it, but I wouldn't recommend that because of the difference in environments on CI & locally.

No, this is a valid way to do it. The only thing that one needs consider is that our default dev env runs on

ragna/environment-dev.yml

Lines 4 to 5 in 55f7fc5

	dependencies:
	- python =3.9

while the docker images uses

ragna/Dockerfile

Line 1 in 55f7fc5

FROM python:3.11

Thus, the command should be run from Python 3.11.

Until now docker-requirements / update (pull_request) job is just testing if current requirements-docker.lock matches the output of the above command and instead of updating it automatically for you it fails. Because the workflow is supposed to open a separate PR & only if it's manually triggered.

Yeah, I imagined the workflow to just merge a PR like this as is and let the bot send a follow-up PR. This what I propose we do here to avoid blocking the PR.

@arjxn-py I saw refactored it so that the bot automatically pushes a commit to PR branch. I dislike this workflow, because it can mess up the branch I have locally. I don't think it is too bad here given that this file shouldn't be touched manually anyway, but I still have my concerns. If you want to have a different workflow, feel free to open a discussion issue. Maybe we can just go for a middle ground and let the bot run on every push to main and automatically send a PR if necessary rather than us starting the workflow manually?

[pmeier]

Thanks Blake!