Change default dependency constraint from ^ to >=

[hhoeflin]

I wanted to request that the default dependency constraint when doing a poetry add mydep is >= and not ^.

The reason for this is forward looking in order to avoid future issues for dependency resolution in the future when many packages use poetry.

Assume the following. A package creator creates package A and uses scikit-image. When A is first created, scikit-image has version 0.16.1, so a poetry add scikit-image results in a dependency of ^0.16.1.

A new package by someone else is created later, let's call it package B. That packages also uses poetry and at the time of writing scikit-image was at version 0.17.1, resulting a dependency of ^0.17.1.

Now - if another package C wanted to use both packages A and B as dependencies, this would not be possible as the version constraints ^0.16.1 and ^0.17.1 are mutually exclusive.

Scitkit-image has been in 'development' mode for a long time and is unlikely to emerge from it soon (similar to what pandas did as well until they switched to 1.0). Also, scikit-image brings out minor version updates regularly, sometimes even more than one per year.

The current default version constraint for dependencies in poetry is bound to cause issues in the future, requiring package mantainers to manually change them to >= in order not to cause issues later.

Other languages use ^ much easier as they allow several versions of the same package to be installed. For python this is not the case, so the ^ constraint that is normal in other languages is problematic here.

[n8sty]

There's the alternative example that's equally frustrating in my experience: When a package undergoes a major version upgrade and an API changes, that change can be breaking in a project that I'm working on, which then forces me to restrain my dependency specification. I don't think there's a ubiquitous solution that works for everyone here, but, for better or worse (I think better because it's more conservative), Poetry seems to have adopted the ^ convention. Changing that now would be surprising to a few people. In general, package owners should be responsible enough to appropriately define their dependencies, and be responsive to any issues that arise. If they aren't, I would try and avoid that package.

[finswimmer]

Poetry believes in SemVer. This is why ^ is the default. There are plenty of discussions out there whether SemVer is good or not and if setting an upper bound is suitable. Each of the arguments have its value. At the end every author have to weight the arguments by itself. So I 100% agree with @n8sty:

In general, package owners should be responsible enough to appropriately define their dependencies, and be responsive to any issues that arise. If they aren't, I would try and avoid that package.

One is free to change the constraint in the pyproject.toml. Letting the user decide, which is the default, is maybe something for a poetry plugin?

[zanieb]

Hi! I took finswimmer's advice and wrote a plugin that helps automate relaxing upper constraints: https://github.com/madkinsz/poetry-relax — it does not directly address this issue yet but it does allow you to easily relax constraints during testing or publishing.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.