[plt-scheme] On PLaneT packages and compatible upgrades

On May 10, 2006, at 11:23 AM, Jacob Matthews wrote:

> I'm not a big fan of this proposal --- programmer-run wizards to 
> generate wrappers strike me as a red flag. Here's a counterproposal 
> that seems simpler to me:

Sure. One minor thing: I consider your proposal an elaboration of 
mine/Matthew's. The "interface extraction" and "ruling out superfluous 
names behind the scenes" sounds like .. a programmer-run wizard to 
generate .. interfaces and .. wrappers behind the scenes. The 
difference is that you are the only programmer in this picture, with 
power-users thrown in later.

-- Matthias


>
> 1. Adding exports to a program remains a compatible upgrade. When a 
> package author submits an upgraded package, the PLaneT server 
> automatically extracts an "interface file" that contains the package's 
> directory structure, and for each Scheme module in that directory 
> structure its list of provided names. It checks this interface file 
> against the interface file for the old version of the package and 
> makes sure that the new one is a proper superset of the old (i.e. it 
> has all the files and directories the old one had, and for each module 
> the new version provides a superset of the names the old one 
> provided).
>
> 2. When mzscheme encounters a
>   (require (planet "file.ss" ("owner" "pkg.plt" maj min)))
> for the first time, it fetches the interface file for ("owner" 
> "pkg.plt" maj min) [or more generally the smallest number that the 
> package specifier could match] from the PLaneT server. Then it 
> downloads and installs some matching package as normal. However, when 
> the loading is complete, it only binds the names listed for the file 
> in the interface file --- even if the loaded module provides `foo', 
> the client doesn't have `foo' bound unless `foo' is in the interface 
> for the package the client thought it was receiving.
>
> What I like about this proposal is that both package authors and 
> package consumers can basically ignore it and things will work the 
> same way they work right now, but with Richard's bug ruled out. No 
> special tools needed, no separating anything out into interface versus 
> implementation files, no requiring major version shifts just to 
> provide an extra function, but this problem is ruled out behind the 
> scenes. Generally I want to keep PLaneT as lightweight as possible for 
> both package producers and package producers, so I favor an approach 
> that works automatically in good cases over one that doesn't.
>
> A somewhat nice side benefit is that I could allow "power users" to 
> write their own interface files and use those instead of the 
> automatically-generated ones.  This would let a programmer separate 
> out a package's interface from its implementation in a nicer way than 
> just creating a directory called "private" and hoping nobody starts 
> relying on individual files in there.
>
> Thoughts?
>
> -jacob