martinfalatic/piptegrator

Makes managing pip dependencies easier

Piptegrator

Tools for managing requirements-driven projects

Run piptegrator --help for usage details

Configuration file which contains requirements files (must be in the repo root if present at all): .piptegrator_config

Note: command line options always override corresponding config file options (they do not append to or aggregate with each other).

Running the tools

Prerequisites - works best with pip>=21.0, pip-tools>=5.5.0, and click>=7.0

The main tool is piptegrator

Given the configuration file .piptegrator_config (sample present in this repo), run:

piptegrator --compile --noenvmods --upgrade --help

For use without a config file, specify the requirements input files as a comma delimited string, e.g.:

piptegrator --compile --noenvmods --requirements test/requirements.in

Gitlab hooks (only with a config file)

The --commit option is used to create and manage upgrade branches based on the changed requirements.txt files. This option requires a gitlab token gitlab_infra_access_token and optionally the pyup API key pyup_api_key in your test environment.

Updating this package

Clone this repo

On a branch, make the required edits

Ensure you update the version number in piptegrator/__config__.py (pre-release? use rc notation, e.g., 1.2.3rc45)

Building and install the distributable wheel

pip install -U build twine && \
rm -rf dist build *.egg-info && \
python -m build --wheel && \
ls -al dist && \
unzip -l dist/*.whl && \
pip uninstall -y piptegrator && \
pip install dist/*.whl

Uploading changes (author only)

python -m twine upload dist/* -u <username>

piptegrator's Issues

Add more logging; make it easier to use locally; standalone report (like the MR details)

• Show calls to pyup.io (if used), total stats
• Local use - initialize the config file for a new user, friendly local management (create a requirements.in file automatically if not present, based on pip freeze output)
• Standalone report for non-MR runs

Add a method to display hard/soft pins in the inputs as part of the MR and log output

It's easy to pin a wayward input to make an upgrade work successfully. However, it's even easier to never look at that pinned dependency again, defeating the purpose of this tooling.

Provide a way for the user to see what items are pinned so they can eventually act upon them and upgrade accordingly when the pin is no longer necessary.

Add uv support

https://astral.sh/blog/uv

Remove PIP_COMPILE_CMD abstraction, add --uv switch and dependency