[squeak-dev] What are environments for
jakob.reschke at student.hpi.de
Thu Sep 29 13:01:29 UTC 2016
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
>> 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.
More information about the Squeak-dev