| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
We have so many nice docstrings, but they aren't really rendered
anywhere (expect locally in your IDE), as we did not include the API
docs anywhere.
This change uses sphinx-apidoc to generate autodoc stubs for Sphinx, so
that the docstrings are actually rendered to HTML. This is not perfect
yet (I'm not too happy about the default modules.rst simply listing one
package), but it is good enough for the start and makes it possible to
actually browse the docstrings in a browser.
|
|
|
|
|
|
This is code that needs to be repeated in possibly several places
(website, API, tests), so it makes sense to have those "high level
actions" a bit abstracted. edit.edit_images was already doing that to a
certain degree, but the code shouldn't have stayed in the view.
|
|
|
|
|
|
This is important if concurrent requests to edit the same track are
made, both for images and later for metadata embedding.
|
|
|
|
|
|
|
|
|
|
|
|
To add more playwright tests and to cut down on the duplicated code, the
helper methods have been put into a small class. This way, we don't have
to add 100 pytest fixtures.
|
|
|
|
|
|
|
|
This should be preferred over dealing with raw alembic now.
|
|
|
|
In case it might be caused by something else than SQLite's inability to
delete a column, it's good to have the actual error written out
somewhere.
|
|
This step would otherwise be done by alembic, which means that we'd
lose the first log messages before calling into alembic.
|
|
-1 is not always the right choice, e.g. when the previous update script
has the same alembic version. Therefore, we actually need to do the
effort to track the "previous alembic" version.
|
|
|
|
|
|
|
|
|
|
This does a lot of changes already. What is definitely not working yet
are the tests, as they still try to put the data into the database - but
that should be easy to fix.
The convenience methods Track.{length,uphill,...} were a bit stupid to
fix, as our template code assumed that those attributes can just be
accessed. As a fix, I've introduced a new class that "re-introduces"
those and can lazily load them from the disk in case the cache does not
exist. This works pretty well, but is not too nice - we end up with a
lot of "proxy" properties.
Other than that, I'm positively surprised how well this has worked so
far, the upgrade scripts seem to be doing good and serving the file
straight from the disk seems to work nicely as well. What isn't tested
yet however is "edge cases", in case a data directory goes missing, ...
|
|
Since we plan on moving the GPX data (and the original copy) into the
data directory, it makes more sense to have a per-track "handle" instead
of having all methods of DataManager take a track_id parameter.
|
|
|
|
|
|
|
|
|
|
This tuple was basically the same as TileLayerConfig, just without the
validation. You could see in the old _extract_user_layers that otherwise
they were 1:1 doing the same job. Therefore, it made sense to remove
TileSource and instead rewrite the code to use TileLayerConfig directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The default session timeout is at 15 minutes, which can be rather short.
Therefore, we now have a "Remember me" option, which optionally saves
the authentication in a cookie (signed of course, so nobody can tamper
with it). This cookie is set to basically never expire, keeping the user
logged in while not messing with the session timeout (which is also used
for other things like flash messages).
We might think about just removing the session authentication completely
and doing everything with cookies, but we'll see about that. We
definitely want to keep two separate timeouts, but the cookie helper
doesn't seem to provide a way to have single cookies last for longer
(short of having a second helper like we currently do).
|
|
|
|
|
|
See https://github.com/tox-dev/tox/issues/2636 - without the rename, tox
fails to recognize the configuration for flake8, as there is a
(non-testenv) section named the same.
|
|
The Poetry FAQ[1] gives some options on how tox and poetry can be used
together, since both of them want to do the virtual env managing. Since
we mostly want to use tox as a venv manager and to easily run multiple
linters, and we want to have poetry do the dependency management, the
method of explicitely using `poetry install` seems to be the most
reasonable. This means we don't have to generate a requirements.txt file
or make duplicated listings of our dependencies in tox.ini.
[1]: https://python-poetry.org/docs/master/faq/#is-tox-supported
|
|
|
|
There seems to be an issue with the latest one.
|
