I suspect that like a lot of us I’m conflicted about having something large like EToys included.

In one sense it’s an important project that needs to be constantly kept up to date and that is best done by having it always there so that anyone refactoring code can’t help but find the EToys code that needs to be updated. Of course, that’s the same argument one might make for Scratch, Magma, all the games, VMMaker and so on.

On the other hand, it ’s obviously ridiculous to have all this stuff in a basic development image and anyone would mad to include so much waste of space nonsense.

So obviously what we really need is a better system for dealing with this. I don’t know what that might be. The 'least unlikely to screw us’ approach would seem to be having a lot of this in the general development image and make sure it is kept properly unload-able (autocorrect tried to make that ‘unlovable’ which seems oddly appropriate) for any deployment usage (like for example Scratch and indeed EToys).

A more complicated idea (and we all love complex cool tools, right?) might be an extension of Chris’ history database that includes all the code of all the packages (hey, slurp in all of squeaksource and so on! Stress Magma!) and when changing code in your image it checks also in the Great Database Of All Things. Must be a PhD or two in that , surely?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Maybe Computer Science should be in the College of Theology