[ANN] Installer bootstrapping scripts

I am pleased to announce "Installer" available in
http://www.squeaksource.com/Installer

I will paste the class comment below to explain....

I think this may make things a bit easier for publishing projects such
as Seaside-Magma-Pier which is fairly complex piece of integration.

enjoy

Keith

--------

Installer is an experiment in creating a Domain Specific Language for
installing a complex project consisting of packages from monticello and
squeakmap of various versions.

One design decision is to be able to paste scripts a workspace and run
and test from there without any special editing.

E.g Using SqueakMap

squeakmap := Installer squeakmap.
squeakmap install: 'DynamicBindings'.
squeakmap open.

or

Installer squeakmap install: 'DynamicBindings'.

or

squeakmap := Installer squeakmap.
squeakmap package: 'DynamicBindings'; install.

Using Monticello

squeaksource := Installer repository: 'http://www.squeaksource.com'.
seaside := squeaksource project: 'Seaside'.
seaside install: 'Comet-lr.8';
        install: 'Scriptaculous'.
       
or

squeaksource := Installer repository: 'http://www.squeaksource.com'       
squeaksource project: 'Seaside';
              install: 'Comet-lr.8;
              install: 'Scriptaculous'.

"for monticello viewer on the repository"
squeaksource project: 'Seaside'; open.

There are some utilities for searching.

"utilities"            
squeakmap packagesMatching: '*ame'  
   
(squeakmap packagesMatching: 'sea*') first.
 
"the very latest seaside release"    
(seaside packagesMatching: 'Sea*') first.  
 

               
___________________________________________________________
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

Sounds exciting. I started to work on something similar.!
Just some questions.
Can we specify
        that we want to load the latest for one component
        do you have a kind of spec for complex setup?

                installer install: #((MC www.squeaksource.com seaside last)
                                        (MC mysource myproject 8)
                                        (SM shout 5)
?

I have been looking for the install of jpierce.
Do you deal with questions raised by the components. Because they  
have a nice package to do that.

On 15 oct. 06, at 11:01, Keith Hodges wrote:

> I think this may make things a bit easier for publishing projects such
> as Seaside-Magma-Pier which is fairly complex piece of integration.

What is the difference to MADistribution that is part of Magritte and
that is used to build the installers of Seaside, Magritte, Pier and
Pier-UnixSecurity?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
>> I think this may make things a bit easier for publishing projects such
>> as Seaside-Magma-Pier which is fairly complex piece of integration.
>
> What is the difference to MADistribution that is part of Magritte and
> that is used to build the installers of Seaside, Magritte, Pier and
> Pier-UnixSecurity?
>
> Lukas
>
To explain,

I had not looked at WADistribution before, now that I have I can see
that it serves a different purpose.

 From what I can see WADistribution is the full black box, one button
installer. As always, professional and seemingly comprehensive.

"Installer" is at the other end of the consumer food chain.

Installer is more intended to be an interactive shell in which
'installer' scripts can be published in a readable form, thus being
transparent and accessible to users. The scripts offer the developer an
executable 'how-to' that can be published on a website and run with cut,
paste and doit.

If you look at the use case. WADistribution is a publishing mechanism.
Whereas 'Installer' is a 'subscribing' mechanism. The packages are out
there being developed all over the place, and interactively the
developer chooses to subscribe to them. Doing so through an 'installer'
in a workspace produces an executable script that can be reused and
adapted to new situations. E.g. the move from 3.8 to 3.9 which is what
Installer grew out of.

Now that I know about WADistribution (the input). I may look at
integrating the two more closely.

best regards

Keith

Send instant messages to your online friends http://uk.messenger.yahoo.com 

This would be good.

Stef

> Installer is an experiment in creating a Domain Specific Language for
> installing a complex project consisting of packages from monticello
> and squeakmap of various versions.

Can you compare this to the simple dependencies of Package Universes?

If Foo could depend on Bar, and you always grabbed the latest version
from within your current working set, what else do you need, in
practice?

My personal experience on Debian is that grabbing older versions of
things is almost always painful, and thus that the intricate
version-specific dependencies of Debian are more harmful than helpful.


-Lex

Lex Spoon wrote:
>> Installer is an experiment in creating a Domain Specific Language for
>> installing a complex project consisting of packages from monticello
>> and squeakmap of various versions.
>>    
>
> Can you compare this to the simple dependencies of Package Universes?
>
>
>  
I am sure that I could if I understood the question.

I think a simple answer may be that Installer makes no attempt to
manage/resolve or otherwise handle dependencies.

My aim is to put the control in the hands of the user through
readability and the ability to interact with the script in the workspace.

My expectation being that once I have made an installation script which
works including all the components that I want/need. (i.e. I manage the
dependencies) Then I can share this in a way that is useable by others
and they can see exactly what I have done and the order in which I have
done it.

does this answer the question?

Keith


Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com 

Keith Hodges <[hidden email]> writes:

Package universes, like many Linux distributions, lets you post a
package that simply depends on other packages.  So, you can post a
package "Keith's Favorites" that depends on a list of other packages
to install.

The user then installs "Keith's Favorites" just as if it were a normal
package.  The package tool will select the latest available [1] version of
all the packages "Keith's Favorites" depends on.

So the question is, do you need anything more for installation
scripts, than the above?  I thought maybe you were working on
dependencies, but you say no.


-Lex


[1] Available, that is, within the package universe the image in
question is working in.

I have found during development that things get a bit confusing where
different people are updating packages simultaneously with their own
fixes etc. I feel (perhaps irrationally) that I need fine grained
control as to what package exactly I have loaded, and in what order and
with what settings or configuration.

It may just be a psychological thing that I don't have confidence in
such a high level automated process that does it all for me.

All that Installer does is to make the details as explicit and as clear
as possible. It also allows me to select and doit (or fork) parts of the
script. It allows me to query the repositories to work out which bits I
need as I go, and it allows me to comment out or omit the parts that I
do not want. (this is useful in a situation where you wish to add some
things to a package in a repository and one of the other packages in the
normal installation process would overwrite portions of that package.
You can omit the second package temporarily).

Finally having got a setup that works, it is possible to publish it, by
publishing the script as is on a web page.

I was looking at the dev image yesterday and even there the level of
automated complexity leaves me feeling that I have lost control of my
image, I don't know what is there or what it all does, so it will take a
bit of getting used to.

As far as dependencies go, in the development process I am not always
sure that the dependencies have been fully worked out, and I would find
it annoying if the system starts to load bits that I dont want.
Installer simply gives you that control, and unlike other similar
solutions it aims to be part of a workspace (or ScriptManager)

Keith






               
___________________________________________________________
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

Keith Hodges a écrit :
> I was looking at the dev image yesterday and even there the level of
> automated complexity leaves me feeling that I have lost control of my
> image, I don't know what is there or what it all does, so it will take a
> bit of getting used to.

I would really like to know what are your questions if you are talking
about the image I maintain. I don't think there is something complex in
what I did. Look at DEVImageConfigurator>>squeakDevImageConfiguration
and you will see everything that is loaded when you download a
squeak-dev image.

To be clear, here are the steps I follow to build a new dev image:

- Download last squeak version from ftp.squeak.org/3.9
- Open the image, then SqueakMap Package Loader
- Upgrade map from the net
- Load last ImageForDevelopers package from SqueakMap
- Execute "DEVSqueakDevImage default installDevImage"
- Wait
- Close windows that should not be in the image (transcript, squeakmap,
two small workspaces)
- Click on the Welcome message to make it appear
- Save and quit
- Rename the image
- Zip the image and the changes files and put the zip in an ftp server


Do you have questions ?

I'm really glad some of you use my image. Please tell me what you think
about it, if you use it, why or why not.

--
Damien Cassou

Damien,

not really questions as such. Thanks for doing the dev image I would
never have got around to trying out shout and some of these other bits
without it.

. For some reason I found it difficult to view the bytecodes for a method.
. I couldn't find the Browser choice preference when I wanted to change it.
. ScriptManager is great, unfortunately it doesnt support variables in
the same way as a normal Workspace, is this something that could be added?

like I said I am just getting used to it

best regards

Keith
>
> Do you have questions ?
>
> I'm really glad some of you use my image. Please tell me what you
> think about it, if you use it, why or why not.
>

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Keith Hodges a écrit :
> Damien,
>
> not really questions as such. Thanks for doing the dev image I would
> never have got around to trying out shout and some of these other bits
> without it.
>
> . For some reason I found it difficult to view the bytecodes for a method.


It would be cool to be able to see the bytecode from the browser. Colin
is working on this. Currently, you can do:


OBSystemBrowser>>#defaultBackgroundColor inspect

and you will get an inspector displaying the bytecode of this method.


> . I couldn't find the Browser choice preference when I wanted to change it.


Second icon, top left of Browser windows, option 'Choose new default
browser'


> . ScriptManager is great, unfortunately it doesnt support variables in
> the same way as a normal Workspace, is this something that could be added?


I'm using ScriptManager to keep the documentation. You still have Shout
Workspace to try code (open... -> Shout Workspace)

Don't know about modifications to ScriptManager.

> like I said I am just getting used to it

Feel free to tell me what you like/dislike. I'm really looking for
comments and remarks.

--
Damien Cassou

On further thought, I have another way to put the situation.

When you build a distribution of packages, there is an important role
for "repackagers".  The importance of repackaging is obvious for a
system like Debian, where the vast majority of the packages were not
made with Debian in mind at all.  It's important for Squeak, too,
because different people have different style and standards for the
packages they post.  Even when all the packages are for Squeak, they
are not always good out of the box for a particular distribution.

Keith's installer boot scripts are one way to repackage an existing
package.  They put a wrapper around an existing package, thus making a
new package.

An alternative, though, is simply to modify the original package and
repost it somewhere else.  Additionally, I suspect that if we *had* at
least one major distribution of Squeak packages, then package writers
would start making their stuff compatible with at least the main
distro, thus reducing the need for repackaging at all.


-Lex