Hi Avi,

> Instances of PackageInfo are created lazily - so until 
> something actually uses (or explicitly registers) a package,
> the instance doesn't exist. If you install a package using
> Monticello or DVS, for example, it'll show up in #allPackageNames.
> Ditto if you create a Monticello working copy, or use MudPie
> to start doing analysis.  But a fresh 3.6 image doesn't have
> any packages in it, just potentially packagable code - if 
> that makes any sense.

No it really doesn't. When we load a package and explicitly tell the
installer that this is a DVS/Monticello package which is based on
PackageInfo then the installer can at least attempt not to throw that
information away even if DVS/Monticello aren't present. Given that the
installer has PackageInfo available and given that the installer knows we
expect to use PackageInfo for managing that code why would it throw this
important information away? All that means is that once we load any of those
tools, we have to manually recreate the package structure.

To me, PackageInfo is kind of the "runtime package information" which is
"just enough" to figure out what belongs to where. We may use it (for
example) to signify an error occuring in a particular package, to associate
meta-information with a package, many different things which are entirely
unrelated to managing the source code.

> I do think that packages have become central enough that 
> we're now ready to move away from this lazy, highly non-intrusive
> notion of package and start being ever so slightly more aggressive
> about packaging

I'm not really talking about "being aggressive" just about "Please don't
throw important information away which you get for free and which cannot be
automatically recreated". Considering that it's trivial to throw PackageInfo
away if you don't like it and that it is far from trivial to guess any of
the packages which may be installed on some user's system it seems really
ridiculous not to keep that single string which identifies the package and
which would allow us to do all sorts of things even in the absence of any
particular source code management system.

Cheers,
  - Andreas