Skin and customization for the French opendata portal based on udata. This project is not maintained anymore. Consider using https://github.com/etalab/udata-front as an alternative.
This PR adds a (quite complex despite my best efforts :-/) workflow to handle processing dependencies through pip-tools, with the added difficulty of a dependency to udata.
Three use cases have been handled:
local dev: relies on a loosened udata req for an easy pip install -e .
CI dev : relies on a dependency to udata@git+https://github.com/opendatateam/udata.git to build requirements and updates and commits the requirements files if udata@master requirements have changed
CI release : use the latest available udata version on pypi and build the requirements files against it, keep only pinned udata version in install_requires
The pre-commit does not handle udata.pip compilation, as this would be too long to run on each concerned commit (needs a git clone of udata). The CI does the job of verifying that requirements are up to date / compatible re udata.
The recommandation from py packaging is that dependencies should not be pinned in install_requires but rather in requirement files https://packaging.python.org/discussions/install-requires-vs-requirements/. Applying this recommendation gets us out of trouble with our new setup of pip-tools on our local dev env.
Things that still not to be adresse with the pip-tools mechanism:
[x] we need to test is this still makes a valid package (i.e. installs correct dependencies when deploying). If not, we can maybe loosen dep only on udata
[x] handle udata-gouvfr (and all plugins) requirements upgrade when udata is upgraded
[x] maybe we want to depend on udata@master when building on CI (except when building tags)
Following use cases should be handled in this PR:
[x] local dev: udata is unpinned in install_requires so pip install -e . should work with whatever udata version is installed in local venv
[x] CI on PRs and master : build requirements tree against udata@master and update them in the PR if needed
[x] CI on release (tags) : build requirements tree against a specific udata version (latest released?), or handle it locally in the deployment process?
This PR adds a (quite complex despite my best efforts :-/) workflow to handle processing dependencies through
pip-tools, with the added difficulty of a dependency to udata.Three use cases have been handled:
udatareq for an easypip install -e .udata@git+https://github.com/opendatateam/udata.gitto build requirements and updates and commits the requirements files if udata@master requirements have changedinstall_requiresThe
pre-commitdoes not handleudata.pipcompilation, as this would be too long to run on each concerned commit (needs a git clone of udata). The CI does the job of verifying that requirements are up to date / compatible re udata.The recommandation from py packaging is that dependencies should not be pinned in
install_requiresbut rather in requirement files https://packaging.python.org/discussions/install-requires-vs-requirements/. Applying this recommendation gets us out of trouble with our new setup ofpip-toolson our local dev env.Things that still not to be adresse with the pip-tools mechanism:
Following use cases should be handled in this PR:
install_requiressopip install -e .should work with whatever udata version is installed in local venvTODO: