2 ms·
My problem with pip-tools is that it only resolves requirements.in files for your existing platform (OS + Python version). Say I'm testing something in CI for
by epage 6y ago
My problem with pip-tools is that it only resolves requirements.in files for your existing platform (OS + Python version). Say I'm testing something in CI for a bunch of platforms, that means to lock my dependencies I need all of those platforms locally. I run into this as well when distributing internal tools at my company, especially since we force requiring hashes.
- globular-toast 6y agoSounds like you're doing it wrong. Pip-tools is for building environments. The common example is a docker container. In that case you control the environment completely and you use pip-tools to ensure the images you build are reproducible. But most python packages are not shipped as environments. They are packages to be installed into user's environments. So you shouldn't be locking your environment when you test it, you should be installing it into a fresh environment like a user would do. You can test against specific major versions of your dependencies, but this is something handled well by tox and doesn't need any locking. In fact, locking will only make your life more difficult as you'll be targeting specific minor versions. Long story short, use pip-tools if you're building docker images or otherwise deploying a tested environment. Don't use it for regular Python packages.