I actually quite like the idea, personally. I use Poetry at work and I thoroughly enjoy it. I work primarily on applications so I think the default constraint

I actually quite like the idea, personally. I use Poetry at work and I thoroughly enjoy it. I work primarily on applications so I think the default constraint of carets is good because my app's not going to break when a dependency is bumped a major version with breaking changes, and I don't care about 50 dependencies (because it's not shipped in our production Docker image, so meh). A 5% brownout on installing is a great idea to the alternatives. I recently went on a dependency updating spree and also happened to update Poetry so already updated our build process and so didn't come across this brownout, but I think I'd prefer it. If it was a plain old print statement and continued to pass our builds I'd never read any deprecation message (my dev env is already setup and if I get green ticks in CI I don't view the logs), and if it was a 100% failure then I'm forced to upgrade it and modify the build process then and there. At least with a brown out I'll be temporarily annoyed, but see the deprecation and then set the temporary skip flag and then plan to make the change to the build process a short time later when sprint commitments allow...