| Age | Commit message (Collapse) | Author |
|---|
|
This is not 100% fietsboek, but it's closely related, and I don't think
setting up a separate site for hittekaart is worth it. At the moment,
this is a bit WIP, as the module sits in its own branch in the
hittekaart repository, but in the long run I want to use this. It also
is an experiment to see how well PyO3 works, as we potentially want to
migrate other parts of fietsboek to Rust in the future (no specifics
yet, but keeping the option available is nice).
In tox.ini, we disable -f for sphinx-apidoc, so that it doesn't
overwrite the modules.rst file. This means that the directory must be
clean if you re-generate the docs (it is on the CI server).
Also, we un-gitignore the modules.rst and hittekaart_py.rst files, as
special cases. The others are still auto-generated, so all good, but
these two we need.
|
|
|
|
https://docutils.sourceforge.io/RELEASE-NOTES.html#release-0-21-2024-04-09.
|
|
I think there are legitimate use cases and flat out not allowing any
lambda to be assigned to a variable is very restrictive.
|
|
It's a start, now it's there and can be improved!
|
|
|
|
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.
|
|
|
|
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
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
