> 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
