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.
Poetry is not perfect, mind you, but it's the absolute best we have in the Python world. Whenever I jump into a new project, switching it to Poetry is one of the first things I do so I have a sane working environment for it.
> The only reason to use pip-tools is because you already know it and you don't want to switch (yet).
Actually, I settled on pip-tools _after_ trying Poetry :-)
> pip-tools is squarely worse than using Poetry.
News to me. Like I said in my original comment: "I personally still find Poetry and Pipenv to be a little heavy-handed for my preferred workflows." A tool that gets out of my way and lets me achieve my goals is a better tool for me. Since Poetry can't meet me where I am, pip-tools is better _for me_.
“I prefer pepsi because coke is too sugary.”
“The only reason you should drink Pepsi is if you already have some. It’s a squarely worse drink than coke.”
poetry works well enough but it seems to bring more complexity with it.
When it works, it's damn near perfect.
When it doesn't work, and that usually involves a problem with a downstream dependency that isn't technically Poetry's fault, it's a massive hassle and sometimes impossible to manually override.