What are environments for

> 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.

> All this is strongly related to Newspeak mechanisms for contructing a
> module, http://bracha.org/newspeak-modules.pdf. Newspeak was conceived with
> solid foundations. Can we reach a solid design by small iterations? Will we
> converge to the same economy of concepts? I just wonder, or should I say
> wander?
>
> That's very interesting. So who has a vision?
> No urge to asnwer this, let's rather make environment transparent ;)
>
> Nicolas
>

> Hi Nicolas,
>
> First, thank you for answering me in the other thread.
>
> 2016-09-28 23:02 GMT+02:00 Nicolas Cellier
> <[hidden email]>:
>> 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.

>> But it's even more complex than that, because the way we create classes:
>> by
>> subclassing another class. So we don't need one environment, we need at
>> least two, one source environment for picking the super class, one
>> destination environment for hosting the subclass. Hmm, the metacello
>> configuration is going to be verbose...
>> OK, OK, but how would we designate an environment in the configuration,
>> is
>> it by name in a sort of Environment registry?
>
> Currently, Environments can be retrieved by name, or you have a
> reference to an Environment object (and treat it as anonymous). In the
> operations mindframe from above, I would not want a Metacello baseline
> or whatever to specify its environments. This configuration would only
> belong to the particular image you want to build. You could still put
> this configuration as a script into another package, of course...
>
> On the other hand, if packages started to abandon class name prefixes,
> being "agnostic" to environments in your package might not be feasible
> in some cases, when you have to do renames to resolve naming
> conflicts.
>
> I look forward to hearing other opinions.
>
>> All this is strongly related to Newspeak mechanisms for contructing a
>> module, http://bracha.org/newspeak-modules.pdf. Newspeak was conceived
>> with
>> solid foundations. Can we reach a solid design by small iterations? Will
>> we
>> converge to the same economy of concepts? I just wonder, or should I say
>> wander?
>>
>> That's very interesting. So who has a vision?
>> No urge to asnwer this, let's rather make environment transparent ;)
>>
>> Nicolas
>>
>
> Best regards,
> Jakob
>
>

> On 9/29/16, Jakob Reschke <[hidden email]> wrote:
> > Hi Nicolas,
> >
> > First, thank you for answering me in the other thread.
> >
> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier
> > <[hidden email]>:
> >> 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?
>

> On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote:
>> On 9/29/16, Jakob Reschke <[hidden email]> wrote:
>> > Hi Nicolas,
>> >
>> > First, thank you for answering me in the other thread.
>> >
>> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier
>> > <[hidden email]>:
>> >> 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
>
>

> 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 <[hidden email]>:
>> On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote:
>>> On 9/29/16, Jakob Reschke <[hidden email]> wrote:
>>> > Hi Nicolas,
>>> >
>>> > First, thank you for answering me in the other thread.
>>> >
>>> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier
>>> > <[hidden email]>:
>>> >> 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
>>
>>
>
>