A toolkit for exhaustively modeling the environmental impact of digital services.
The current perimeter is the carbon footprint associated with the manufacturing and usage of servers, storage, network (usage only) and end-user devices necessary for the existence of a web digital service. It is also now possible to model the production of edge devices (like video game consoles, smartphones, servers, etc.) and describe the unitary usage by device over its usage phase, to get the environmental footprint of the deployed fleet. Edge devices support hierarchical grouping via EdgeDeviceGroup with per-component unit multiplicity (nb_of_units), enabling complex fleet structures with nested device and sub-group counts.
Other environmental impacts (water, rare earth metals, etc.) will be added soon through an integration with the Boavizta API, and the lifecycle phases of device transportation and end of life are currently considered negligible.
e-footprint requires Python >= 3.12, with no cap on 3.x minor versions: it follows a rolling window
where "supported" means the latest Python minor versions for which every compiled dependency ships wheels.
Today that's 3.12 and 3.13; the next minor is added once its wheels land. The <4.0 bound in
requires-python is a major-series guard, not a ceiling on the rolling window.
Check out INSTALL.md.
Here is the link to the e-footprint documentation. There you will find a description of all the e-footprint objects, their parameters, the relationship between the objects and the calculated attributes and their graphs.
You can explore the model’s graphical interface, which is also open source and found in the Boavizta e-footprint interface repository. Please send an email to e-footprint’s main maintainer, Vincent Villet if you wish to give feedback !
Checkout our open source e-footprint modeling use cases.
pip install efootprint
You can then run the jupyter notebook tutorial to familiarize yourself with the object logic and generate an object relationship graph and a calculation graph as HTML files in the current folder.
# Todo once to setup jupyter kernel
poetry run ipython kernel install --user --name=efootprint-kernel
# Start Jupyter server with poetry
poetry run jupyter notebook tutorial.ipynbNo local Python setup needed: build the image once, write your model script, then run it inside the container.
docker build --build-arg EFOOTPRINT_VERSION=<version> -t efootprint .
docker run --rm -v "$PWD":/work efootprint python /work/build_model.pyThe current directory is mounted at /work inside the container, so build_model.py (and any file
paths it references, e.g. an output HTML graph) resolves relative to your working directory. See
Dockerfile. This image isn't published anywhere yet — build it locally as above.
Check out INSTALL.md.
The code has been architectured to separate modeling from optimization from API logic. The goal is to make contribution to the modeling logic as straightforward as possible.
- Modules that deal with modeling logic are located in efootprint/core.
- Optimizations (having the model rerun the right calculations whenever an input attribute or a link between objects changes) are dealt with in efootprint/abstract_modeling_classes.
- All json serialization / deserialization logic, that is essential for making the web interface work, are found in efootprint/api_utils.
Check out CONTRIBUTING.md