Guillermo P. one of the lead bootstrapper with Pavel. K and C. Demarey explained the under the cover decisions made around the Pharo 7.0 bootstrap…
Is there a scope and purpose statement for the bootstrap somewhere?
Not writen that I know of. Maybe we should do it. But from many discussions here in the team I’d define the pharo bootstrap as a pharo environment that is
– minimal (in the sense that it keeps only stuff required to run)
– clean (in the sense that there is the less dead code and dead dependencies as possible)
– and is able to grow (in the sense that you can install new code on it). Think that Pharo is not just the bootstrap. People will not accept a Pharo without a development environment, without a debugger or a workspace.
These three points are a long term goal I woud say, and particularly the last point is in big conflict with the first one. You can have an image that executes code but has no compiler for example.
So making a trade-off but always going towards that goal, what we decided with Christophe one year and a half ago to:
– select a minimal set of packages that would belong to the bootstrap image
* To run, you need the Kernel.
* To be able to install new code you need some kind of I/O and some way to transform the input as classes/methods. Thus we chose to put also basic command line handlers, files, and the compiler. We discussed about putting a flavour of Fuel (say Tanker) instead of the compiler, but Tanker was not stable as it was only experimental and nobody used it for real; the compiler was much more stable as we use it everyday; and besides, Tanker was depending on the class builder, so it only allowed us to remove the compiler but not the class builder.
* To be clean, we started looking at the dependencies of those packages.
– We finished in a selection of about 53 packages. Remember that Pharo itself has nowadays around 464 packages…
RPackageOrganizer default packages size “464”
So this was as good as a ~10% of the original image. Good enough to have a first version.
– And we started working on dependency analyses on them. The following report made by Christophe lists all the bootstrap packages and their dependencies, and reports when a new dependency is introduced.
See what the dependency graph looks of the bootstrap
and extrapolate to the entire image :).
And that, after we worked a LOT to cut off/separate/untangle/decouple those 53 packages from the rest, rewrite parts of the system (a big example of it is the SessionManager).
Now, this is of course not the end. There are still lots of things to do.
– the kernel can be still cleaned up even more
– we could implement some sort of binary serializer specialized for classes and methods to shrink even more the bootstrap
– the rest of the image has still to be cleaned. Nowadays on top of the bootstrap Monticello and Metacello are bootstrapped using manual a approach and afterwards, the rest of the image is loaded by using a Baseline
That baseline can be enhanced, splitted in smaller baselines. This require non-bootstrap packages to be revisited, have checked their dependencies and so on…
So what you see in that list is the result of several decisions and a lot of work. And the focus was to release something and not die in the process. Hope that answers the question (I will copy past this and put it into some wiki btw)