Pharo Bootstrap (Was Re: Refactoring File Package)

> El sáb., 6 de jun. de 2015 a la(s) 12:39 p. m., Ben Coman
> <[hidden email]> escribió:
>>
>> On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito
>> <[hidden email]> wrote:
>> > Actually we just want to have a kind of split in:
>> >
>> > - essential
>> > - non-essential
>>
>> I guess you have scripts outside the image to shrink the image and
>> then bootstrap it.  However these are not necessarily visible to
>>
>> everyone and I am wondering once the bootstrap goal is achieved
>> you will handle the entropy of ongoing development by many others
>> accidentally introducing dependencies that breaks the bootstrap?
>
>
> Well no. I try to not do that. Currently what I have working is:
>
> - a metacello configuration describing the packages+versions that
> will be part of the built kernel
>
> - a simple script that will create the initial objects of an image before
> class creation (e.g., create Smalltalk, initialize the symbol table, etc). I
> want this guy to be the smallest as possible to avoid what you
> describe above

> - a script to initialize the image after class creation. e.g., create the
> first process, and execute some class side initialize.
>
> Then again, the ad-hoc bootstrap scripts try to be minimal to avoid
> being impacted. Of course they could be impacted by changes of
> APIs, but I think it is still controllable in the size of the scripts :).
> And then, that is why I try to push as many "modularity" concerns to
> Pharo itself, to keep these scripts small.
>
>>
>>
>> Also what I have seen is classes being moved out of their current
>> packaging (sorry I forget the details, but I think it was moved out of
>> System) into a new top-level package, which I think loses something
>> in structure and might pollute the top-level packages.
>
>
> Yes, mea culpa there. Some times when extracting classes from one
> package I didn't put the new package under the System-* or
> whatever top level package.
>
> However, I believe also that the agreement on what are the top-level
> packages is kind of implicit and obscure to me. I remember some
> discussions in the list with the Alt browser from Thierry using the idea
> of top level packages, and others talking about the navigation of the
> system. I check the latest Pharo Image and I found:
>  - AST (should be system?)
>  - Announcements (should be system?)
>  - Collections (should be system?)
>  - Files (should be system?)
>  - Networking (should be system?)
> ...

>
>>
>> So considering the recent discussion of package tags, I wonder if
>> somehow we could have a "Bootstrap" tag and realtime critics that
>> complain if Bootstrap-tagged-class references any
>> non-Bootstrap-tagged-class.  There might even be several levels of
>> Bootstrap tags.  This would improve ongoing visibility of the
>> bootstrap structure and help the rest of us to not shoot it in the
>> foot.
>>
>> I wonder also if tags might also be extended to method protocols, so
>> you can have a method with the "accessors" tag and also the
>> "bootstrap" tag, so that even a Bootstrap-tagged-class can be further
>> minimised by the methods it needs during bootstrap.  Otherwise I
>> guess to minimise the methods in a Bootstrap-tagged-class, later
>> extension by another package could not add methods to the
>> "accessors" protocol.
>
>
> That would be amazing if I could add meta-data to packages to only
> install specific classes. Because we could keep a coarser granularity
> of packages while keeping the bootstrap small.
>
> However, the problem is that you cannot predict what
> classes/methods the bootstrap will use.

> So far, I'm using the class
> builder to build classes in the bootstrap. In such way, I ensure that
> all classes that I create will honor the same invariants as a normal
> class and I don't have to duplicate the creation code :).
>
> That means that we can change the internals of the class builder as
> long as we don't change the API + preconditions and the bootstrap
> will continue working.
>
> Guille