Kevin Dangoor wrote: > On 10/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > But if somebody's doing a fresh install without any of the > > dependencies, then yeah, "easy_install TurboGears" should work just > > fine now. > > I'll hold off on changing the install instructions until the "without" > part of that sentence goes away. This is really good news, though. I > didn't realize that just putting the download URL there would do the > trick.
EasyInstall scans PyPI entries' home page and Download URL for downloadable links, and it's not averse to scarfing any download links for dependencies, while it's at it. :) > > In the meantime, I guess I should figure out why upgrading installed > > dependencies doesn't work. :( > > Could it be something to do with the fact that 0.2.2 is the released > version and 0.2.3 used by TurboGears is a dev version? I'm afraid so. The problem is rather subtle, I had to step through the dependency resolver in pdb to find the issue. The problem is that one of the other packages (SQLObject, I think) requests version 0.2.2 or better, so the resolver goes, "okay, I can do that, I've got 0.2.2 locally", and then once the nested processing for SQLObject is done, it goes to look at the other TurboGears dependencies and goes, "oh darn, TurboGears wants 0.2.3 and I've already picked 0.2.2 as the version to use, I can't back up now! Waaaaa!" Well, that's anthropomorphizing, but you get the idea. :) It looks like my semi-naive dependency resolution algorithm has finally met its match, complexitywise. This is really cool because it means there's now enough stuff out there declaring dependencies to make it worthwhile to make it more complex. :) I had been using a depth-first algorithm, but now it looks like I should switch to breadth-first, because that will allow the depender (TurboGears) to override the dependees (e.g. SQLObject), as long as the depender's choices are also acceptable to the dependees. And, I now have a nice test case for it. :)
