

Dependency Graph Nightmares in Python - zeeg
http://justcramer.com/2013/01/29/dependency-graphs-and-package-versioning/

======
lvh
One of my favorite parts about Twisted is its API deprecation policy. When an
API breaks like that, it's a bug. We do time based releases (like ubuntu), and
in practice you should get at the very least six months, usually a year, to
fix things: and that's only when we actually change APIs, which is rare.

If an API is just imperfect, stuff just gets added around it, eg getPage has
been superseded by Agent for a while but it still works fine.

People may think this is a property of boring software that has jumped the
shark. Maybe that's true. Maybe that's a good thing too.

------
webology
It's pretty much a given that moving from one major release to another is
going to break things. Since you're using Django as an example then I should
point out that this is why Django spent half of it's life in a pre-1.0 state
where there were major changes from the .91, .95, and .96 branches which broke
every _minor_ version up until 1.0 before it was officially released. Remember
when the admin used to be tied to each model instead of decoupled? I sure do -
[https://docs.djangoproject.com/en/dev/releases/1.0-porting-g...](https://docs.djangoproject.com/en/dev/releases/1.0-porting-
guide/)

I'm half surprised you didn't just create a requests-1.0 branch and then give
the third party libraries time to upgrade instead of pinning to shas. I have
several projects that depend on requests<1.0 which will run just fine for some
time.

------
daGrevis
Is is somehow possible to have requests v.9 and requests v1 (or any other
library w/ different versions at the same time) working on the same project?
That would fix these dependency problems.

