Ability to override/ignore sub-dependencies

• I have searched the issues of this repo and believe that this is not a duplicate.

(However, it is related to https://github.com/sdispater/poetry/issues/436).

Issue

In the dark, old world of Python packaging, sub-dependencies are handled very poorly. If I recall correctly, pip will happily install a sub-dependency despite conflicting versions being specified by two direct dependencies… in fact I think which version it ends up installing depends on the order in requirements.txt. Yuck! Only very recently has it even started issuing a warning for cases like this.

In contrast, poetry does this right. It computes the entire dependency tree and will complain if there are conflicts anywhere in the tree.

But… many packages out there are not specifying their dependencies properly. Even if they are, there’s always the possibility that their specified dependencies are a tighter range than they strictly need to be.

Is there a way to tell Poetry to force a specific version (or version) range of a dependency in cases like this — or in other words, to ignore a dependency specification of another dependency somewhere in the tree? If not, should there be?

[sdispater]

I don’t think this is desirable. This would require a lot of work and add complexity to the resolver - which is already complex due to the Python specific ecosystem - because of some packages specifying their dependencies poorly. I don’t want Poetry to have to make up for a lack of proper tools or proper specifications, there is already a lot of work to be done as it is.

This is the job of each package’s maintainers to ensure their dependencies are correct and loose enough to not create conflict.

If we ever want to have an ecosystem similar to what other languages already have, we have to draw the line somewhere and enforce everyone to contribute to the common goal. Poetry helps with that by making it easier to build and manages Python projects.

[danielkza]

@sdispater While you are completely correct in principle, in reality there are cases where not being able to perform overrides means being completely unable to install some packages, specially when multiple projects specify conflicting version constraints.

Waiting for the whole ecosystem to improve will take years, and in the meanwhile Poetry is unusable in some cases, which is a shame considering it brings lots of improvements in other areas.

As a practical example, awscli requires a particular version range colorama while docker-compose requires another. That makes it completely impossible to install both simultaneously, and neither of the projects are willing to make a change. But in practice both programs work correctly (since I’ve been using them in the same venv for years).

Even other package managers that work with more “well-behaved” ecosystems allow overrides e.g. Maven, SBT and others in Java world.