Having them in image can indeed be useful. I am testing against REST backends, and well, this is a destructive test to say the least. Not easy to replay as much as I want.
I hope that with the Bootstrap we'll be able to have a set of "Batteries Included" distributions. Kind of like we have Moose today, which I like very much as I do not have to load parts from all over the place. On http://tcl.tk there are also a number of such distributions: * the "Batteries Included" ActiveTcl (http://www.activestate.com/activetcl) with its various support levels [which would be good to emulate for the Pharo Pro business proposition] * TclKit / StarKits concept (http://wiki.tcl.tk/52). TclKit is a BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their supported features. * Build your own from sources. TclKit allows one to build special kit, using a command line tool, similar to what we discuss for loading packages easily. http://wiki.tcl.tk/10558 We do have an image and the TclKit has a VFS (Virtual File System) bundling everything in a single file. So, basically, one runs things with tclkit hello.kit. Quite reminiscent of pharo Pharo.image I'd say. Question 1: Which top 5 packages/configurations would you find useful to have available in a distribution? 1- 2- 3- 4- 5- Question 2: What do you consider to be the top 3 use cases of a Pharo Distribution for your own use? 1- 2- 3- Best, Phil ` On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisi...@gmail.com> wrote: > > 2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopol...@gmail.com>: > >> No, please, kernel test should have the fewer dependencies as possible! >> > I would say this dependency is needed. > >> And again i'll hold my position: whoever wants to load it can do it. >> There is no need to put it there by default. >> > Do you know how much easier it would be to design and test FileSystem with > mocks. Code and tests will be much better and simpler from the beginning. > And I could said it about any package which provide abstractions. > > Now no project which is part of Pharo can use mocks for tests. So it is > not question of loading it for own project. Pharo contributors can't use > mocks. > > And there is another story. Imaging Ruby guys join Pharo development (not > real story :)). Many years In Ruby people use mocks and "human should" > assertions. Most TDD evolution was from Ruby. I imaging their impression > about Pharo "the best for TDD". > > And generally I would said we have quite bad tests in system. They are > slow, they corrupt image. Mocks will help to improve this situation. >
