almet/la-chariotte
1
0
Fork 0
mirror of https://framagit.org/la-chariotte/la-chariotte.git synced 2025-04-29 02:12:39 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: use mkdocs

Browse source
This commit is contained in:
Alexis Métaireau 2023-12-17 17:12:01 +01:00
parent 5664be5074
commit b39b43386d
16 changed files with 553 additions and 309 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
.readthedocs.yaml Normal file
View file

@ -0,0 +1,12 @@
version: 2
build:
os: ubuntu-22.04
tools:
python: "3.11"
mkdocs:
configuration: mkdocs.yml
python:
install:
- requirements: docs/requirements.txt

310
README.md
View file

@ -1,308 +1,12 @@
# La Chariotte # La Chariotte
<img src="la_chariotte/static/img/logos/logo_la_chariotte.png" title="Logo de la Chariotte" height="150"/> <img src="docs/assets/logo.png" title="Logo de la Chariotte" height="150"/>
La Chariotte est une application de gestion de commandes groupées. La Chariotte is a web application to handle grouped orders.
Elle est publiée sous licence libre Affero GPL, développée et maintenue par [Hashbang](https://hashbang.fr/). - [Public server](https://chariotte.fr)
- [Online documentation](https://docs.chariotte.fr)
## Contribuer This project has been initially developped and published by [Hashbang](https://
hashbang.fr/) under an [Affero GPLv3](LICENSE) license, and is now maintained
Si vous souhaitez contribuer au projet de la Chariotte, merci beaucoup ! and developed by a team of volunteers.
La permière étape est de cloner le projet et d'obtenir le statut de développeur. Une fois que c'est fait, vous pouvez :
- choisir une tâche dans le board que vous voulez réaliser, et vous l'assigner - si vous ne savez pas quelle tâche faire, n'hésitez pas à écrire à laetitia@chariotte.fr
- créer une nouvelle branche **à partir de develop** dont le nom dira ce que vous voulez faire
- réaliser la tâche, sans oublier d'écrire et de lancer les tests (voir plus bas)
- créer une Merge Request, contenant le plus de détails possible sur ce que vous avez fait
Ensuite, un mainteneur de la Chariotte pourra relire votre code et proposer des améliorations/poser des questions si nécessaire. Seuls les mainteneurs peuvent merger dans develop et main.
Encore merci, et bon code !
## Versions - semantic versionning
Les fonctionnalités développées dans les différentes versions sont listées dans le fichier [CHANGELOG.md](https://gitlab.com/hashbangfr/la_chariotte/-/blob/main/CHANGELOG.md).
Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :
le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,
le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,
le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles.
La version est à mettre à jour dans `la_chariotte.__init__.py` lors des releases.
## Développement
Cloner le projet :
```bash
git clone git@gitlab.com:hashbangfr/la_chariotte.git
```
### Environnement virtuel.
Pour éviter que les bibliothèques nécessaires au projet ne rentrent en conflit avec celles de votre système, il peut être utile d'installer un environnement virtuel :
```bash
python3 -m venv .venv
```
Une fois l'environnement virtuel installé, vous pouvez l'activer :
```bash
source .venv/bin/activate
```
### Dépendances
La Chariotte utilise Weasyprint pour la génération de PDFs, qui nécessite certains paquets sur votre machine. Vous pouvez suivre [les instructions de cette page](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) pour les installer.
Ensuite, vous pouvez récupérer les dépendances python :
```bash
pip install -r requirements-dev.txt
```
### Base de données
La Chariotte nécessite une base de données, et est actuellement compatible avec PostgreSQL ([instructions d'installation ici](https://www.digitalocean.com/community/tutorials/how-to-install-postgresql-on-ubuntu-20-04-quickstart)).
Pour le développement, nous vous conseillons de créer une base de données nommée ```chariotte``` accessible par l'utilisateur et le mot de passe du même nom.
Dans une invite postgresql, entrez ceci :
```SQL
CREATE ROLE chariotte WITH
LOGIN
NOSUPERUSER
CREATEDB
NOCREATEROLE
INHERIT
NOREPLICATION
CONNECTION LIMIT -1
PASSWORD 'xxxxxx';
```
```SQL
CREATE DATABASE chariotte
WITH
OWNER = chariotte
ENCODING = 'UTF8'
CONNECTION LIMIT = -1
IS_TEMPLATE = False;
```
### Fichier de configuration
Créez un fichier de configuration dans lequel vous pourrez spécifier la configuration qui est utile pour vous. Nous allons le nommer ici ```local_settings.py```.
```python
from la_chariotte.settings import *
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "chariotte",
"USER": "chariotte",
"PASSWORD": "chariotte",
"HOST": "localhost",
}
}
```
### Lancement du serveur
Tout devrait être maintenant prêt pour pouvoir lancer le serveur :
```shell
python manage.py migrate --settings=local_settings
python manage.py runserver --settings=local_settings
```
Pour créer un superutilisateur, qui aura accès à l'interface admin (/admin) :
```shell
python manage.py createsuperuser --settings=local_settings
```
### Travailler sur le frontend
Nous utilisons bulma comme framework CSS. Vous pouvez l'installer en utilisant la commande suivante :
```bash
npm install bulma
```
Vous aurez aussi besoin de sass :
```bash
npm install -g sass
```
Vérifiez que vous utilisez la bonne version de sass :
```bash
sass --version
# used for developement: 1.59.3 compiled with dart2js 2.19.4
```
Recompiler dès que des changements sont detectés dans les fichiers scss.
```bash
sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css
```
Ou bien préférez compiler vers CSS au coup à coup :
```bash
sass --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css
```
### Lancer les tests
Lancer les tests avec pytest :
```bash
pytest
```
Si il y a des erreurs [isort](https://pycqa.github.io/isort/), on peut lancer isort pour trier les fichiers :
```bash
isort .
```
Si il y a des erreurs [black](https://black.readthedocs.io/en/stable/), on peut lancer black pour linter le code :
```bash
black .
```
### Tests de l'envoi de mails
Pour tester l'apparence des mails, on peut utiliser [Sendria](https://github.com/msztolcman/sendria) :
```bash
pip install sendria
sendria --db mails.sqlite
$NAVIGATOR http://127.0.0.1:1080
```
Attention : si vous n'activez pas `sendria --db mails.sqlite` quand vous travaillez en local, vous aurez une erreur en commandant : `[Errno 111] Connection refused`.
## Architecture de l'application
Les différentes applications Django créées sont :
- ``order``, pour gérer tout ce qui tourne autour des commandes
- ``accounts``, pour gérer la création de comptes. Pour la connexion, la déconnexion et le changement de mot de passe, on utilise l'application auth intégrée à Django.
- ``mail``, pour l'envoi des mails.
A l'état actuel, le diagramme de classes est le suivant :
```mermaid
classDiagram
GroupedOrder "item_set" <-- Item
GroupedOrder "order_set" <-- Order
Order "ordered_items" <-- OrderedItem
Item "orders" <-- OrderedItem
OrderAuthor "author" <-- Order
CustomUser "grouped_orders" <-- GroupedOrder
class GroupedOrder{
name
deadline : DateTime
delivery_date : Date
place
description
orga : CustomUser
total_price
}
class Item{
name
grouped_order : GroupedOrder
ordered_nb
total_price
max_limit
}
class Order{
grouped_order : GroupedOrder
author : OrderAuthor
price
created_date
note
}
class OrderedItem{
order : Order
nb
item : Item
}
class OrderAuthor {
first_name
last_name
phone
email
}
class CustomUser{
first_name
last_name
email
}
```
## Conventions de nommage
### Nommage des branches
Chaque branche doit être nommée sous la forme `category[/ticket-ref]/description`.
*category* détermine le type de modification que vous comptez effectuer au sein de la branche :
- `feature` pour ajouter une fonctionnalité au projet
- `fix` pour corriger un bug
- `test` pour effectuer des changements n'étant associé à aucun besoin déjà spécifié
- `doc` pour effectuer des changements relatifs à la documentation (readme notamment)
- `refactor` pour effectuer un changement au sein du code sans conséquence sur l'application
Vous pouvez ajouter une catégorie si le besoin s'en fait sentir, tout en s'assurant que le sens soit bien compréhensible de l'extérieur.
Entre la catégorie et la description peut s'insérer la référence du ticket Gitlab relatif à la branche.
La description de la branche, en anglais et en kebab-case, doit décrire de manière très succinte l'objectif de la branche : dans quel but elle a été créée sans entrer dans le détail.
Bons exemples :
- `feature/72/improve-pdf-generation`
- `fix/117/deadline-increments-on-duplicated-commands`
- `doc/explain-conventions`
- `refactor/99/is_ongoing-to-is_open`
Mauvais exemples :
- `fix-some-stuff`
- `readme`
- `feature/add-a-cool-ui-element-when-the-cursor-passes-over-the-calendar-where-the-user-can-also-choose-the-associated-hour`
- `fix/edit-order/views/order.py-to-replace-is_ongoing-by-is_open`
### Noms des commits
Les noms de commits doivent être constitués de deux parties : un sujet et un corps (optionnel).
Le sujet fait office de titre du commit ; il se suffit souvent à lui-même et doit expliquer brièvement le but du commit.
Si besoin, le message de commit peut être enrichi d'un corps qui permet de détailler plus en détails ce qui a été modifié et pourquoi (mais pas comment !).
Les noms des commits doivent respecter ces 7 règles d'or pour garantir une homogénéité dans le projet:
- Sépare le sujet du corps avec une ligne vide
- Limite la ligne de sujet à 50 caractères
- Met une majuscule à la ligne de de sujet
- Ne finis pas la ligne de sujet avec un point
- Utilise le mode impératif dans la ligne de sujet (IMPORTANT)
- Limite la taille de ligne (*wrap*) du corps à 72 caractères
- Utilise le corps pour expliquer le quoi et le pourquoi (et pas le comment)
Les détails de cette méthode sont détaillés dans ce tuto : https://cbea.ms/git-commit/
Bons exemples :
- `Refactor system X for readability`
- `Remove deprecated method`
- `Release version 1.4.2`
Mauvais exemples :
- `Changing behaviour of X`
- `add submit button.`
- `Edit order.py line 72 to improve efficiency by adding recursive algorithm`

BIN
docs/assets/logo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 65 KiB

11
docs/changelog.md Normal file
View file

@ -0,0 +1,11 @@
# Changelog
Given a version number `MAJOR`.`MINOR`.`PATCH`:
- `MAJOR` is updated when there are **incompatible changes**,
- `MINOR` is updated when there are **backwards-compatible feature additions**,
- `PATCH` is updated when there are **backwards-compatible bug fixes**.
### 1.0.0 (date)
- Basic features.

62
docs/contributing/contributing.md Normal file
View file

@ -0,0 +1,62 @@
# Contributing
You want to contribute to the project ? First, thank you very much! We'll try to do our best to help you getting started.
The first step is to clone the project, you can find more information about that in the [getting started guide](../install.md). Once that's done, you can:
- choose a task [on the board]() and assign it to yourself - if you don't know which task to do, feel free to reach to us.
- create a new branch **from develop** naming it to reflect what you want to do
- complete the task, without forgetting to write and run tests (see below)
- create a Merge Request, containing as many details as possible about what you have done
Then, a maintainer will be able to review your code and suggest improvements/ask questions if necessary. Only maintainers can merge into develop and main.
Thanks again, and happy coding!
## Working on the frontend
To recompile the files as soon as changes are detected in the scss files.
```bash
sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css
```
## Running tests
Run tests with `pytest`:
```bash
pytest
```
## Formatting your code
Once you're ready, you'll need to ensure your code is formatted the right way.
We're using [isort](https://pycqa.github.io/isort/) to fix the import order,
and [black](https://black.readthedocs.io/en/stable/) for general linting.
You can run them with:
```bash
isort .
black .
```
## Working with emails
To test the appearance of emails, you can use [Sendria](https://github.com/msztolcman/sendria):
```bash
pip install sendria
sendria --db mails.sqlite
$NAVIGATOR http://127.0.0.1:1080
```
## Docs
We're using [MkDocs](https://www.mkdocs.org/) for this documentation. If you want to
build it locally, just run:
```bash
mkdocs serve
```

66
docs/contributing/naming.md Normal file
View file

@ -0,0 +1,66 @@
# Naming Conventions
We're trying to enforce some naming rules for our work. The goal is to be consistent.
## Git branches
Each git branch should be named in the form `category[/ticket-ref]/description`.
`category` determines the type of change you intend to make within the branch:
- `feature` to add a feature to the project
- `fix` to correct a bug
- `test` for making changes that are not associated with any specified need
- `doc` for making changes related to documentation (readme in particular)
- `refactor` for making a change within the code without consequence on the application
You can add a category if needed, making sure the meaning is easily understandable from the outside.
Between the category and description, the Gitlab ticket reference related to the branch may be inserted.
The branch description, in English and in kebab-case, must briefly describe the purpose of the branch: the purpose for which it was created without going into detail.
Good examples:
- `feature/72/improve-pdf-generation`
- `fix/117/deadline-increments-on-duplicated-commands`
- `doc/explain-conventions`
- `refactor/99/is_ongoing-to-is_open`
Bad examples:
- `fix-some-stuff`
- `readme`
- `feature/add-a-cool-ui-element-when-the-cursor-passes-over-the-calendar-where-the-user-can-also-choose-the-associated-hour`
- `fix/edit-order/views/order.py-to-replace-is_ongoing-by-is_open`
## Git commits
Commit names should consist of two parts: a subject and a body (optional).
The subject acts as the title of the commit; it often suffices by itself and should briefly explain the purpose of the commit.
If needed, the commit message can be enriched with a body that allows for more detailed explanations of what was modified and why (but not how!).
Commit names must follow these 7 golden rules to ensure uniformity in the project:
- Separate the subject from the body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use imperative mood in the subject line (IMPORTANT)
- Limit the line size (*wrap*) of the body to 72 characters
- Use the body to explain the what and the why (and not the how)
Details of this method can be found in this tutorial: https://cbea.ms/git-commit/
Good examples:
- `Refactor system X for readability`
- `Remove deprecated method`
- `Release version 1.4.2`
Bad examples:
- `Changing behaviour of X`
- `add submit button.`
- `Edit order.py line 72 to improve efficiency by adding recursive algorithm`

13
docs/contributing/releasing.md Normal file
View file

@ -0,0 +1,13 @@
# Releasing a new version
## Semantic versioning
The features developed in the various versions are listed in the [changelog](../changelog.md) file.
Given a version number MAJOR.MINOR.PATCH, increment:
- the MAJOR version when there are incompatible changes,
- the MINOR version when there are backwards-compatible feature additions,
- the PATCH version when there are backwards-compatible bug fixes.
The version should be updated in `la_chariotte.__init__.py` during releases.

107
docs/deploy.md Normal file
View file

@ -0,0 +1,107 @@
# How to deploy
!!! info "This is how **we** deploy"
This page describes how the main instance is deployed, and is mainly meant as a
way to share the knowledge. You can obviously do things differently.
## Services
"La chariotte" uses different domains:
- **docs.chariotte.fr**, the docs you are reading now. It's handled by [readthedocs.org](https://readthedocs.org).
- **chariotte.fr**, the main instance. It's deployed on Alwaysdata
- **blog.chariotte.fr**, our blog. It's [a static website](https://gitlab.com/la-chariotte/la-chariotte.gitlab.io) deployed on Gitlab pages.
## The main instance
### Alwaysdata, our hosting provider
[Alwaysdata](https://www.alwaysdata.com) offers [a free plan for open source
projects](https://www.alwaysdata.com/en/open-source/), which we are using for
the main instance of la chariotte.
Thanks to them for supporting open source!
### Getting access
To get access, you'll need to generate an ssh keypair, and give your public key to a known admin.
```bash
ssh-keygen
```
This will generate a private a public key. You need to share the **public** key.
On unix systems, it's stored under `~/.ssh/id_rsa.pub` by default.
### Connecting to ssh
Once your key is generated and you're known to the server, you can connect there.
```bash
ssh chariotte@ssh-chariotte.alwaysdata.net
```
### Configuration file
The chariotte application is run by [uwsgi](https://uwsgi-docs.readthedocs.io/
en/latest/), managed by AlwaysData.
The production settings are stored in `~/ la_chariotte/prod_settings.py`, and
the secrets are defined in the admin console.
### The different sites
In the AD console, here are the defined sites:
- `app.chariotte.fr`, redirecting to `chariotte.fr`
- `chariotte.fr/static`, hosting the static files, it just serves the collected static files stored in `/static/`
- `chariotte.fr`, the main website, defined in the next section
`chariotte.fr` is configured as a Python WSGI app:
- application path: `/la_chariotte/la_chariotte/wsgi.py`
- working directory: `/la_chariotte`
- venv location: `/venv`
Environment variables:
```
DJANGO_SETTINGS_MODULE=prod_settings
```
### How to deploy
To deploy a new version, we'll need to:
- get the new code
- update the database
- collect the static files
- restart the daemon
Here's how:
```bash
# Activate the venv
source venv/bin/activate
cd la_chariotte
# Get the code
git fetch
git checkout tag # if we're using a tag, otherwise, just checkout the main branch
python manage.py updatedb
python manage.py collectstatic
```
Then you'll need to restart the server from AD's interface.
### What about SSL certificates?
The SSL certificates are issued directly by AlwaysData (they use [Let's Encrypt]
(https://letsencrypt.org/) behind the scenes)
## Mails
Mails are hosted by alwaysdata, as part of their opensource plan.

59
docs/development/architecture.md Normal file
View file

@ -0,0 +1,59 @@
# Application Architecture
The various Django apps created are:
- ``order``, to manage everything around the orders
- ``accounts``, to manage account creation. For logging in, logging out, and changing passwords, we use Django’s built-in auth application.
- ``mail``, for sending emails.
At the moment, the class diagram is as follows:
```mermaid
classDiagram
GroupedOrder "item_set" <-- Item
GroupedOrder "order_set" <-- Order
Order "ordered_items" <-- OrderedItem
Item "orders" <-- OrderedItem
OrderAuthor "author" <-- Order
CustomUser "grouped_orders" <-- GroupedOrder
class GroupedOrder{
name
deadline : DateTime
delivery_date : Date
place
description
orga : CustomUser
total_price
}
class Item{
name
grouped_order : GroupedOrder
ordered_nb
total_price
max_limit
}
class Order{
grouped_order : GroupedOrder
author : OrderAuthor
price
created_date
note
}
class OrderedItem{
order : Order
nb
item : Item
}
class OrderAuthor {
first_name
last_name
phone
email
}
class CustomUser{
first_name
last_name
email
}
```

3
docs/index.md Normal file
View file

@ -0,0 +1,3 @@
# La chariotte - Documentation
![Logo](assets/logo.png)

126
docs/install.md Normal file
View file

@ -0,0 +1,126 @@
First, clone the project
```bash
git clone git@gitlab.com:la-chariotte/la_chariotte.git
```
## Virtual environment
To prevent the project's necessary libraries from conflicting with those on your system, it may be beneficial to install a virtual environment:
```bash
python3 -m venv .venv
```
Once the virtual environment is installed, you can activate it:
```bash
source .venv/bin/activate
```
## Installing the dependencies
!!! info "Weasyprint"
We are using [Weasyprint](https://weasyprint.readthedocs.io/) for `.pdf` generation, which requires certain packages on your machine. You can follow [the instructions on this page](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) to install them.
Then, you can retrieve the Python dependencies:
```bash
pip install -e ".[dev]"
```
And the frontend dependencies:
=== "Yarn"
```bash
npm install
```
=== "npm"
```bash
yarn install
```
## Setting up the database
We recommend using PostgreSQL for now ([installation instructions here](https://www.digitalocean.com/community/tutorials/how-to-install-postgresql-on-ubuntu-20-04-quickstart)).
For development, we recommend creating a database named ```chariotte``` accessible by the user and password of the same name.
In a PostgreSQL prompt, enter this:
```sql
CREATE ROLE chariotte WITH
LOGIN
NOSUPERUSER
CREATEDB
NOCREATEROLE
INHERIT
NOREPLICATION
CONNECTION LIMIT -1
PASSWORD 'xxxxxx';
```
```sql
CREATE DATABASE chariotte
WITH
OWNER = chariotte
ENCODING = 'UTF8'
CONNECTION LIMIT = -1
IS_TEMPLATE = False;
```
## Create a configuration file
Create a local configuration file:
```python title="local_settings.py"
from la_chariotte.settings import *
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "chariotte",
"USER": "chariotte",
"PASSWORD": "chariotte",
"HOST": "localhost",
}
}
```
## Compile the CSS files
We use bulma as a CSS framework.
Make sure you are using the correct version of sass:
```bash
sass --version
# used for development: 1.59.3 compiled with dart2js 2.19.4
```
Recompile as soon as changes are detected in scss files.
```bash
sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css
```
Or prefer to compile to CSS on a per-occurrence basis:
```bash
sass --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css
```
## Start the server
Everything should now be ready to start the server:
```shell
python manage.py migrate --settings=local_settings
python manage.py runserver --settings=local_settings
```
To create a superuser, who will have access to the admin interface (/admin):
```shell
python manage.py createsuperuser
```

3
docs/requirements.txt Normal file
View file

@ -0,0 +1,3 @@
mkdocs==1.5.3
pymdown-extensions==10.4
mkdocs-material==9.4.14

29
docs/settings.md Normal file
View file

@ -0,0 +1,29 @@
# Settings
Here are the useful settings you can define. We're generally extending [Django settings](https://docs.djangoproject.com/en/4.2/ref/settings/), so any setting there could be used here.
This page documents the additional setting.
## CONTACT_MAIL
The contact mail that will be displayed at the bottom of the page.
```python title="chariotte_settings.py"
CONTACT_MAIL = "name@example.org"
```
## GITLAB_LINK
The URL to the git repository.
```python title="chariotte_settings.py"
GITLAB_LINK = "https://gitlab.com/your-repository"
```
## PROJECT_NAME
This is the main name of the project. By default it's set to `"La Chariotte"`
```python title="chariotte_settings.py"
PROJECT_NAME = "Groupement d'achat du CRAC"
```

2
la_chariotte/settings.py
View file

@ -7,7 +7,7 @@ from sentry_sdk.integrations.django import DjangoIntegration
BASE_DIR = Path(__file__).resolve().parent.parent BASE_DIR = Path(__file__).resolve().parent.parent
BASE_URL = os.getenv("BASE_URL", "http://127.0.0.1:8000") BASE_URL = os.getenv("BASE_URL", "http://127.0.0.1:8000")
PROJECT_NAME = os.getenv("PROJECT_NAME", "La Chariotte") PROJECT_NAME = os.getenv("PROJECT_NAME", "La Chariotte")
GITLAB_LINK = "https://gitlab.com/hashbangfr/la_chariotte" GITLAB_LINK = "https://gitlab.com/la-chariotte/la_chariotte"
CONTACT_MAIL = "laetitia@chariotte.fr" CONTACT_MAIL = "laetitia@chariotte.fr"
# SECURITY WARNING: keep the secret key used in production secret! # SECURITY WARNING: keep the secret key used in production secret!

47
mkdocs.yml Normal file
View file

@ -0,0 +1,47 @@
site_name: La chariotte
site_description: An application for grouped-orders
repo_name: la-chariotte/la_chariotte
repo_url: https://gitlab.com/la-chariotte/la_chariotte
nav:
- How-tos:
- Getting started: install.md
- Contributing:
- How to: contributing/contributing.md
- Naming conventions: contributing/naming.md
- Releasing: contributing/releasing.md
- Developer:
- Architecture: development/architecture.md
- Configuration:
- Settings: settings.md
- Deployment: deploy.md
- Changelog: changelog.md
theme:
name: material
homepage: https://chariotte.fr
palette:
- scheme: 'default'
media: '(prefers-color-scheme: light)'
primary: 'custom'
toggle:
icon: 'material/lightbulb'
name: 'Switch to dark mode'
- scheme: 'slate'
media: '(prefers-color-scheme: dark)'
primary: 'custom'
toggle:
icon: 'material/lightbulb-outline'
name: 'Switch to light mode'
features:
- navigation.sections
- navigation.footer
markdown_extensions:
- pymdownx.magiclink
- admonition
- pymdownx.superfences:
custom_fences:
- name: mermaid
class: mermaid
format: !!python/name:pymdownx.superfences.fence_code_format
- pymdownx.tabbed:
alternate_style: true
combine_header_slug: true

12
pyproject.toml
View file

@ -11,11 +11,12 @@ dependencies = [
"django>=4,<5", "django>=4,<5",
"psycopg2-binary>=2,<3", "psycopg2-binary>=2,<3",
"sentry-sdk<1", "sentry-sdk<1",
"xhtml2pdf", "xhtml2pdf>=0.2.11,<1",
"icalendar", "icalendar>=5.0.7,<6",
"base36", "base36>=0.1.1,<1",
"django-weasyprint", "django-weasyprint==1.1.0.post1", # see below
"html2text", "weasyprint==52.5", # pin weasyprint to not depend on latest libpango
"html2text>=2020.1.16",
] ]
[tool.setuptools] [tool.setuptools]
@ -39,6 +40,7 @@ dev = [
"pytest-django>=4,<5", "pytest-django>=4,<5",
"pytest-cov>=4,<5", "pytest-cov>=4,<5",
"diff-cover>=4,<5", "diff-cover>=4,<5",
"pymdown-extensions==10.4",
"pytest-black<1", "pytest-black<1",
] ]