search

arbeitsgruppe-digitale-altnordistik / Sammlung-Toole

A new look on Handrit.is data
https://arbeitsgruppe-digitale-altnordistik.github.io/Sammlung-Toole/
MIT License
0 stars 0 forks source link

Update procedures #73

Closed kraus-s closed 2 years ago

kraus-s commented 2 years ago

Make script that does:

BalduinLandolt commented 2 years ago

In the most recent commit I set up some basic scripts for initializing and updating the submodule.

But I don't think that's good enough because it requires people to know they have to execute those commands, in order to run the app.
Sadly, setting it up, so it checks the submodules before running streamlit is harder than it should be, if we want to remain OS independent.
The best solution I could figure is as follows: Have a python runner script, that first manages the submodule stuff, and once that's done, runs the actual app. The downside to this is that it would update the submodules each time, which would slow down startup significantly. But I could add a pipenv run quick command, to skip the submodules part.
@kraus-s any thoughts? Should I proceed with that?

kraus-s commented 2 years ago

I was thinking: If we make the switch to SQLite anyways, we could do away again with the submodule. Instead, we could have a version-controlled db file, which is part of the repo. Whenever we do a new release, we update the db and we provide an updater script, that streams the xml-files from github and/or downloads the entire repo and deletes it again after successful db update. This script would be used by us for db updates for new releases and by those who don't want to wait for a new release when handrit added three new MS entries. The version of handrit used could be saved in logs and/or version info of some kind (i.e. "About" in streamlit webapp). What do you think?

BalduinLandolt commented 2 years ago

I'm a bit torn, honestly. On one side, this would allow DOIs pointing to a version of the tool, to also point to a consistent version of the data, which seems hugely important. On the other side I'm very sceptical about tieing the data to our release cycle, because like that we'd have to keep releasing in order to let our data stay up to date.

I opened PR #80 which refines the submodule solution. I feel we should give this more thought, discuss it at some point, and then see if we want to change it or not.
And for now, the submodules should at least work, I think, which is something

BalduinLandolt commented 2 years ago

80 now prompts a warning in the GUI if the submodule has been updated after the handler has loaded the data. Like this it's up to the user to hit wipe cache and rebuild handler manually. I think that's an acceptable compromise, and good enough for now.