| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The biggest change in the dependencies is of course SQLAlchemy 2. On the
good side, we didn't need to do many code changes --- in regards to
actual Code, none!
On the better side, we now have way better type checking for SQLAlchemy
models, thanks to SQLAlchemy's integration with mypy (which we now
properly enable). Yay!
That also means though that many type hints needed to be updated, or
rather, the code using the SQL objects. Especially the difference
between Optional things and existing things has been clarified in a few
places, either by using sensible defaults, or by asserting that the
value is not None. That at least gives us an AssertionError instead of
an AttributError.
|
|
|
|
|
|
See https://github.com/mozilla/bleach/issues/698
nh3 is a small wrapper around https://crates.io/crates/ammonia - more
Rust code in Fietsboek! \o/
The default seems to be to strip unknown tags instead of replace them
with htmlentities, which is fine. Then the <script> tags are completely
gone.
|
|
This makes it consistent with the other scripts (fietsupdate,
fietscron), and makes the argument parsing setup a bit nicer to read.
|
|
|
|
|
|
|
|
|
|
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 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, ...
|
|
|
|
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
|
|
This is the first step, in the next step, we should actually use
request.config.
|
|
|
|
importlib.metadata was introduced in 3.8 :-(
|
|
|
|
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.
|
