Jeff Younker wrote:
Thats a great theory, but that's not how the real world works. Python packages are an ecology where there will be inconsistencies between different minor versions of the same package.
I'm not sure what you're arguing here. If you're saying that having a version management system won't make these sorts of problems go away, then I fully agree. But that's no reason not to have a verion management system. If you have one, then at least it provides a clear set of rules for people to try to adhere to, and helps show up when they aren't being adhered to, so that the problem can be fixed.
A legitimate bug fix may break behavior that other packages depend upon while correcting the behavior for others.
If it does that, then it will break other packages anyway, whether a versioning system is being used or not. So I would say it's introduced another bug which in turn needs to be fixed. The versioning system is not the cause of this and can't be blamed for it.
What is needed is a Real Versioning System. A system in which a library or application consists of:
1) files 2) a dependency link map
That sound like a dependency management system to me, not a version management system. They're different things, although dependency management can benefit from having a clear way of labelling versions.
When the system loads the package it links in the dependent modules. Then you can get a system where:
Application A imports B v 1.1 and C v 2.3
and
Application D imports B v 1.4 and C v 2.6.
Ummm... how is that any different from what I suggested? If in the Python context "loads" means "uses an import statement". -- Greg