I agree that a simple workspace example first is better.

It could be an updated version of the example taken from

     http://wiki.squeak.org/squeak/6220


    seaside := (Environment named: #Seaside)
      import: Smalltalk globals;
      importSelf;
      exportSelf;
      yourself.

    magma := (Environment named: #Magma)
      import: Smalltalk globals;
      importSelf;
      exportSelf;
      yourself.

    app := (Environment named: #AwesomeApp)
      import: Smalltalk globals;
      import: seaside;
      from: seaside import: {#Session -> #SeasideSession};
      import: magma;
      from: magma import: {#Session -> #MagmaSession};
      importSelf;
      exportSelf;
      yourself.

I assume with the changes from Nicolas of today this will look different.

Just two environments would be sufficient.

--Hannes

On 9/29/16, Jakob Reschke <jakob.reschke at student.hpi.de> wrote:
> I don't know if this would be quicker to implement than a Project
> type, but at the moment I would appreciate a simple Workspace that
> evaluates everything in a specific Environment. Projects would be far
> more useful to actually write code in another Environment, of course.
>
> 2016-09-29 14:37 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>> 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
>>
>>
>
>