|
|
|
|
|
|
by wirrbel
3038 days ago
|
|
|
Don't forget that usually you'll start to sort your requirements into dev requirements and production requirements which makes these packaging scripts much more complicated. https://github.com/jazzband/pip-tools would be what I used before pipenv came to be. |
|
|
1. `pip-sync`, An easy way to ensure my local environment actually matches my defined requirements. I guess the pipenv version of this would be `pipenv uninstall --all && pipenv install` which isn't quite as elegant, but perhaps good enough.
2. The ability to create more than two requirement sets. For my projects it's often handy to three sets of requirements:
• Normal production requirements end users will need to run the app
• CI requirements needed for testing, but not running the app in production (Selenium, Flake8, etc)
• Local debugging tools (ipython, ipdb)
I could include my local debugging tools in the `--dev` requirements, but then I'm unnecessarily making my CI builds slower by adding requirements for packages that should never actually be referenced in committed code. Alternatively, I could leave them out of my dependencies entirely, but then I have to remember to reinstall them every time I sync my local env to ensure it matches the piplock file.