On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote:
> On 9/29/16, Jakob Reschke <jakob.reschke at student.hpi.de> wrote:
> > Hi Nicolas,
> >
> > First, thank you for answering me in the other thread.
> >
> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier
> > <nicolas.cellier.aka.nice at gmail.com>:
> >> Without clear goals or vision, fixing could essentially mean "let
> >> Environment be transparent", that is let it remain a promise, a
> >> potential,
> >> whithout too many side effects... Not exactly YAGNI, just a bit of
> >> over-engineered nice piece of code that might serve later. OK this sounds
> >> like a mandatory first step.
> >
> > I don't quite get what you mean by transparent, other than fixing it
> > and enhancing the documentation to shed some light on what it is, why
> > it is there and how to use it.
> >
> >> But then, what feature are we after?
> >> I have read bootstrapping, sandboxing, letting concurrent packages and/or
> >> versions co-exist, stop prefixing class names with pseudo namespace...
> >> So environment are about reducing global variable scope.
> >>
> >> For me, the essential decisions are in these questions:
> >> - how will environments and source-code-management interfere?
> >> - how are we going to specify reproducible artifacts (images)?
> >>
> >> Are we going to use environment "statically" like in VW, just like
> >> namespaces are in many languages? That somehow means that the SCM will
> >> have
> >> to be environment aware.
> >>
> >> Or are we going to transfer this responsibility at a higher level, like
> >> Metacello for example? In this later case, we have greater flexibility,
> >> but
> >> assembling an image means telling which package is installed into which
> >> environment, then which import are necessary for each environment.
> >
> > It depends on whether you look at Environments as a developer's tool
> > (like, e. g., Java packages) or an operator's/administrator's tool
> > (like, e. g., Docker containers, maybe). In this discrimination
> > developers can also be operators while they gather the dependencies
> > for their projects, for example.
> >
> > Treating them as an operator's tool, I could imagine to create a new
> > environment for every "Squeak app" you want to deploy in a production
> > image. Installing that app via Metacello or the Squeak Map could
> > (optionally?) create such an environment, isolating its dependencies
> > (and their particular versions) from other apps in that image.
> > Alternatively, you could install that app or library package into an
> > existing environment that you must specify then. But I do not consider
> > myself an operator, so I might be off conventional paths here...
> >
> > Another thing I have in mind is running a new test case against many
> > older versions of a package (and its dependencies?) to find out which
> > version introduced a regression, without changing the "main"
> > environment each time when another version is checked out. Imagine you
> > would want to do this with the Kernel or Collections package. I would
> > want "throwaway" environments for this.
> >
> > My current naive use case is to hide from a Pharo package that I want
> > to get going in Squeak the fact that in Pharo some classes have been
> > renamed. I just want to make the older Squeak classes available under
> > their changed names, without really renaming the classes themselves
> > and without doing a big search&replace in the client package. This is
> > probably bound to fail, because the interface has probably changed as
> > well, but a generalization of this would be compatibility-, adapter-
> > or emulation environments.
> 
> Another maybe simple use case could be to have a project specific
> environment set up when you enter a project
> (http://wiki.squeak.org/squeak/1020).
> 
> We now have very nicely cleaned up Project code in Squeak 5.1
> 
> 1) Subclass MorphicProject --- MyMorphicProject
> 2) Subclass PasteUpMorph  --- MyPasteUpMorph
> 3) Override #initialize in MyMorphicProject and use MyPasteUpMorph
> 4) ... some more adaptations ..... to enter a new Environment -- how?
>

I like this idea a lot.

I would love to see a simple "hello world!" level example of Environments.
If someone could make an EnvironmentsDemoProject that opens a new project with
something that changes Duck>>speak ==> 'quack' to Duck>>speak ==> 'moo',
I think it might really help me to understand how to use Environments.

Dave