I am with you on the scenario but I think 'early failure' is good because a mostly compatible upgrade (widening the API) may have introduced other small changes and all packages between yours and the modified one may suffer. So I would love to see that our social processes push people to repair against 'widened' APIs as soon as possible i.e. you'd file a but report against one of these packages. -- Matthias
On Nov 18, 2013, at 11:56 AM, Greg Hendershott <[email protected]> wrote: >> In my experience, using plain require and later adding 'except-in' when a >> service module decides to widen its interface is a much simpler approach >> than pre-emptively using 'prefix-in' or 'only-in', especially if you need >> (almost) everything from a (possibly large) library. -- Matthias > > When building locally, I feel the same way. > > The problem is when my package depends on other-package, and users are > building my stuff via `raco pkg`. If other-package widens its > interface in a way that conflicts with my package, I will probably > first learn about it from a user who can't get my thing to install. > Then I need to do a fire drill to update my package. (Unless I used > only-in or prefix-in, in which case I'm probably OK.) > > Actually it could be worse. If my package depends on other-package, > which in turn depends on other-other-package, and the breakage is with > the last two? Now it's a fire drill, but even if I wanted to roll out > of bed to hot-fix it, I can't do that myself. (Unless it's understood > best-practice to use only-in or prefix-in, and other-package's author > did so.) > > > I understand that breakage could happen in other ways, too. I'm just > saying this is _a_ vector for backward incompatibility that might not > be obvious to everyone. Either because they weren't aware of it, at > all. Or because they're aware of the possibility, but their estimation > of the consequence is framed by building locally instead of users > building in the wild. ____________________ Racket Users list: http://lists.racket-lang.org/users
