[Catalog-sig] [Distutils] "just use debian"

[Tarek Ziadé]

On Tue, Sep 30, 2008 at 6:37 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> 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.

Exactly, you can't control everything from your package unless you
work in an isolated environement like virtualenv or zc.buildout
provides, so I can't see any solution unless someone is taking care of
it at a higher level :(

maybe PyPI though, can automate this, when a package is uploaded, by
browsing all dependency and
finding relevant conflict ? PyPI "knows" all the packages out there.

At least display those conflicts somehow ? or warn about them.

(I am pushing this to catalog-sig as well, sorry for the cross-post. I
do thing though, these mailing lists should merge)


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



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/