What are environments for

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

What are environments for

Nicolas Cellier
Environment carry great promise and potential...
But for now, it's only that.

I recently read "let's fix environments".
+1 too to that generous idea.
But what does it mean?

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.

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

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



Reply | Threaded
Open this post in threaded view
|

Re: What are environments for

Jakob Reschke-2
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

Reply | Threaded
Open this post in threaded view
|

Re: What are environments for

Hannes Hirzel
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?



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

Reply | Threaded
Open this post in threaded view
|

Re: What are environments for

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: What are environments for

Jakob Reschke-2
In reply to this post by Hannes Hirzel
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: What are environments for

Hannes Hirzel
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 <[hidden email]> 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 <[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
>>
>>
>
>