| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
This seems like something we should do rather earlier than later. Using
black takes away the pain of manually formatting the code, adhering to
the style guidelines and it takes away bikeshedding over minor things.
|
|
|
|
|
|
It would be nice to gradually improve the typing situation in Fietsboek.
At least the parts that do not do heavy metaprogramming should have
types. For most of the API, we already have types in the doc strings, so
those could be removed then.
|
|
While it should be fine the way it was, we might want to introduce more
"secret keys" (like for additional cookies), for which we would need
more secrets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We forgot to include the CSRF token here.
|
|
This takes away the pain of dealing with default values or value
conversions in main()
|
|
This is the first step, in the next step, we should actually use
request.config.
|
|
This way, we not only save the decompression time, we can also save
bandwidth! We *might* even consider using brotli, which seems to be
widely supported and has even better compression ratios, but brotli
compression of full efficiency is also slow.
Ideally, we'd save a "fast compressed" version of the GPX file on
upload, and then have a slower background-queue re-compress them with
higher settings. That however should probably wait till we move the GPX
data out of the database(?!), then we can even serve the data straight
with a FileResponse.
|
|
|
|
|
|
|
|
Poetry does the right thing by default, so no more need to declare this.
|
|
|
|
|
|
We're proxying all tiles through Fietsboek now, which means that no
external services get to see the users' IPs. Therefore, we can disable
this popup with a good conscience.
|
|
This was leftover code from before the tile-proxy times.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
