| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
3.7 will reach EOL in June of 2023, so it doesn't really make too much
sense to forcefully stick with it for much longer - especially since
upgrading gives us a few nice things (walrus, type subscription on
builtins).
3.9 is shipped by Debian 11 (stable), so everything should be good.
|
|
|
|
|
|
|
|
|
|
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 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.
|
|
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.
|
