Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
What are environments for? (Sept 2016, E)
Last updated at 10:18 am UTC on 29 September 2016
[squeak-dev] What are environments for

Nicolas Cellier
Wed, Sep 28, 2016 at 11:02 PM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list


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


Answer


Jakob Reschke
Thu, Sep 29, 2016 at 12:58 AM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
Reply | Reply to all | Forward | Print | Delete | Show original
Hi Nicolas,

First, thank you for answering me in the other thread.

2016-09-28 23:02 GMT+02:00 Nicolas Cellier :
> 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


Environments update (Sept 2016, F)