[Distutils] "just use debian"

[Ian Bicking]

Chris Withers wrote:
> Tarek Ziadé wrote:
>>> Tarek Ziade wrote:
>>>> For KGS I agree that this is a big work, but there's the need to 
>>>> work at a
>>>> higher level that in your package
>>> Why? You really need to explain to me why the dependency information 
>>> in each
>>> of the packages isn't enough?
>>
>> Because you can keep up with the dependencies changes, removed, or 
>> introduced
>> by a package you depend on.
> 
> Why can this not be expressed in the dependency information in the package?

I tried this briefly for a while when Setuptools first came out, and I 
found it completely unmaintainable.

Say I have a package that represents an application.  We'll call it 
FooBlog.  I release version 1.0.  It uses the Turplango web framework 
(1.5 at the time of release) and the Storchalmy ORM (0.4), and Turplango 
uses HardJSON (1.2.1).

I want my version 1.0 to keep working.  So, I figure I'll add the 
dependencies:

   Turplango==1.5
   Storchalmy==0.4

Then HardJSON 2.0 is released, and Turplango only required 
HardJSON>=1.2, so new installations start installing HardJSON 2.0.  But 
my app happens not to be compatible with that library, and so it's 
broken.  OK... so, I could add HardJSON==1.2.1 in my requirements.

But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a 
security bug.  Turplango releases version 1.5.1 that requires 
HardJSON>=1.2.2.  I now have have to update FooBlog to require both 
Turplango==1.5.1 and HardJSON==1.2.2.

Later on, I decide that Turplango 1.6 fixes some important bugs, and I 
want to try it with my app.  I can install Turplango 1.6, but I can't 
start my app because I'll get a version conflict.  So to even experiment 
with a new version of the app, I have to check out FooBlog, update 
setup.py, reinstall (setup.py develop) the package, and then I can start 
using it.  But if I've made other hard requirements of packages like 
HardJSON, I'll have to update all those too.

So... that's the kind of thing I encountered with just a couple 
dependencies, but in practice it was much worse because there were a lot 
more than 3 libraries involved.  I now think it is best to only use 
version requirements to express known conflicts.  For future versions of 
packages you can't really know if they will cause conflicts until they 
are released.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org