| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is due to compatibility reasons, such that the code works in Python
<3.10.
|
|
importlib.metadata was introduced in 3.8 :-(
|
|
|
|
|
|
|
|
|
|
I'm a slave to the linters now.
|
|
This is nice if we hit a 404 or something on the source, especially with
user-configured sources.
As a small side, we now don't give the client the URL in the error
message, as that could contain API keys that we don't want to leak.
|
|
Now, we can add Thunderforest maps with
thunderforest.api_key = ...
thunderforest.maps = cycling ...
|
|
This change shuffles around quite a bit because we no longer hardcode
our map layers in osm-monkeypatch.js, but instead can pass them through
from the Python code. This allows us to dynamically define extra layers,
for example to disable layers the admin doesn't want, or to add extra
layers that are not yet available.
This change for example allows to embed thunderforest maps by adding the
following to the config:
fietsboek.tile_layers.tf_cycling = TF Cycling
fietsboek.tile_layers.tf_cycling.url = https://thunderforest.com/...
fietsboek.tile_layers.tf_cycling.access = restricted
The next step is to make the Thunderforest maps a bit easier to access
(by providing special support for those), but for now, this seems like a
good first step and the necessary groundwork.
|
|
|
|
1. This makes Fietsboek faster because we don't have to wait for the
timeout on every single request.
2. This is better for the servers, as we don't add more requests when
they're already overloaded.
|
|
This avoids blocking the whole pipeline
|
|
|
|
setup.py is the very old style for packaging, so I wanted to replace it
with something more "modern". pyproject.toml seems like the way to go in
the future.
At first, I wanted to simply configure setuptools using pyproject.toml,
but that support is in beta and seemed to cause some issues with the tox
virtualenvs.
Poetry seems to work fine and provides a better dependency resolver
(given that dependencies are actually specified well) and some other
goodies. For users, nothing much should change, as "pip install" still
works.
|
|
|
|
This doesn't really do anything yet, but it serves as a starting point
and sets the alembic version.
|
|
|
|
|
|
|
|
|
|
This makes it easier to add some useful hooks, such as "self.tell" to
output information about the update to the user, and it ensures the
pre_alembic/post_alembic methods exist.
|
|
|
|
|
|
This makes sure that the exit code is set properly
|
|
This does two things:
1. fietsupdate update --help works (before it errored because the
required argument is not given)
2. fietsupdate help works (like git help ...)
|
|
This moves the updater scripts into a subfolder, which keeps them
separated better from the rest of the package. In addition, we now have
the "fietsupdate" command instead of using "python -m
fietsboek.updater".
|
|
This prevents the empty "Tagged as:" to be shown
|
|
|
|
|
|
If we apply a migration that takes us from "v1" to "v2", then a
downgrade needs to apply the reverse of this migration - not the one
that goes from "v1" to "v0", and not "no migration".
The previous code managed to not do this, as it would see "v1-v2" as
applied and therefore skip it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that the filtering is done via SQL, it is not enough for the user
and the objects to be in the session - they need to be in the database,
similar to the added tracks.
Note that it was not entirely necessary in this case, since the tracks
are public, but it provides the proper functionality in the future.
|
|
By not using an OUTER JOIN, we were missing the tracks that did not have
an associated track cache. The filters already deal with this case (by
having a IS NULL check), but we need to actually include those rows by
using an outer join here.
|
|
This is a continuation of the previous two commits, in which we do the
filtering in the SQL query instead of retrieving all objects and then
filtering them in Python.
The generated SQL can be quite complex, but
1) most of it comes from the logic of determining the visible tracks and
2) it is built piece-by-piece with small Python functions.
Therefore, it should be okay.
|
|
While this requires some logic duplication, and it does mean that we
have to generate complex SQL queries, it is also the preferred way of
doing this, as we do not have to load all the tracks just to filter them
out in the application.
|
|
The speedup is probably negligible, as a single user shouldn't have
enough tracks to really make a difference, but it is good practise to
let the SQL engine do the filtering and only retrieve the objects that
we actually need.
|
|
|
|
|
|
|
|
|
|
|
|
|
