[hannibalhorn]

Definitely not a fan. :-( Sometimes you know what you want and the package itself is wrong.

For example, I have a dependency that specifies pandas at ^0.25.1, and now I can't install it alongside pandas 1.0+ without forking or getting a PR upstreamed (even though I know it works with all versions of pandas just fine.)

In the node ecosystem, yarn actually recognizes that this situation exists and provides a mechanism to override, along with some good descriptions of situations where it's necessary[1].

[1] https://classic.yarnpkg.com/en/docs/selective-version-resolu...

[cauthon]

I agree. This doesn’t seem like it’s going to fix dependency management in python, just replace the existing problems with arguably greater ones.

For example, this seems like _terrible_ behavior. Even more, it’s inconsistent with the philosophy behind the new change that installing dependencies shouldn’t create conflicts.

> This also means that, when you run a pip install command, pip only considers the packages you are installing in that command, and may break already-installed packages. It will not guarantee that your environment will be consistent all the time.

[disgruntledphd2]

We should all answer the survey about that, because it is really, really crazy.

Conda dies the same thing and it's super frustrating.

[Macha]

The survey is now closed

[rbarrois]

From what I understand, the issue with the previous behaviour is that, although it enabled you to bypass the issue of that specific package, it could also install conflicting versions you didn't know about.

For your specific use case, wouldn't it be better to have a flag `--override-constraints=` where you provide explicitly overridden constraints only for the packages you're interested in?

[globular-toast]

Also not a fan. I like the fact that pip is relatively "stupid". It means you can use pip-tools if you want proper to have a fully resolved graph, but pip should always do what you want.

Poetry is neat but the Unix philosophy wins, as usual. Each tool should do one thing and do it well. Pip was much better at doing what pip does than poetry is. Not any more.

[scrollaway]

To hell with the Unix philosophy on this topic. Poetry is amazing, and as a user of python for 15+ years I would much rather have one tool like poetry solve the problem of "python dependencies and packaging", than 25 tools to solve the myriad of sub problems hidden in it.

[hannibalhorn]

Then switch to poetry, why break pip?

The dependency I referenced actually uses poetry, and the reason it's borked is because "poetry add pandas" back when 0.25.1 was current meant effectively adding "poetry==^0.25.1" to requirements.txt, even though the one line of actual code that uses pandas works on pretty much any version I've ever seen.

[globular-toast]

That's great. It's your choice and I would happily use poetry to contribute to your projects. But why change pip? We can have both ways. Pip+pip-tools has been around for a lot longer and it's been working very well for freezing dependencies. Even better than npm/yarn.

[scrollaway]

I get you, though pip isn't particularly changing, at least not in the context you seem to be implying? The dependency resolver is a good move, implementation seems poorly conceived though from the sound of the other comments.