[racket] Should we _always_ use `only-in` or `prefix-in` when `require`-ing packages?

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 <greghendershott at gmail.com> 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.