Config Browser for Metacello

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

Config Browser for Metacello

Andreas.Raab
Folks -

I finally got around to do a quick mock-up of what I'm having in mind as
UI for dealing with the Configurations package. If you want to try it do
this:

* Load the latest Configurations from the inbox
* Load the ConfigBrowser from the inbox
* Fire up ConfigBrowser via "ConfigBrowser open"

What you'll find is something that looks suspiciously like the SqueakMap
UI :-) which is no surprise since that was what I wanted. The goal is
that we derive lots of useful information from the configurations
itself, such as:

- The category the config is in. The system category provides the
top-level structuring in the browser.
- The class comment. The configuration's class comment is utilized as
the comment for the package itself.
- Various config info. The list of available versions, the blessing
status, the description of versions are all derived directly from the
configuration.

There's still a lot of things open and missing. First, this doesn't
actually install anything yet :-) but then again it's a UI mock-up at
this point to get some feedback.

Also, there's no way to specify 'optional' installs. I'm starting to
think that Metacello might be going down the wrong path with it's
'default group' usage - I think a group should have a 'default'
attribute that indicates whether to include it in a default install.
That way, we could actually provide a list of options to install (which
is difficult currently because it's not clear whether the groups overlap
or not). But I'll bring this up with Dale and we can see how to deal
with that.

In any case, that's kind of what I'm thinking of in terms of UI. If
someone wants to hack along, please go right at it. This is 'work in
progress' and by no means finished but I think it's good enough to see
what I'm trying to do.

Feedback welcome! Patches even more :-)

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Göran Krampe
Hi!

On 05/19/2010 07:44 AM, Andreas Raab wrote:
> Feedback welcome! Patches even more :-)

I haven't even looked yet - BUT... I got reminded by a nice "feature" in
Lunar Linux's package management tools when you were discussing "default
groups" etc. Perhaps I misunderstood - but I guess its about "questions
to the user when installing stuff".

Earlier Installer introduced (Keith IIRC) some mechanism to provide
automatic answers to regular popup dialogs etc. A hack, but still.

In Lunar Linux each module (=package) has a defined *list* of "options"
with default answers. A typical such question is whether to install an
optional "nice package" - in fact, those questions may be automatically
derived from a list of "optional dependencies" - but whatever.

When you perform an installation of a module the dependency system
figures out the total list of packages to install - and then compiles a
*complete* list of questions for all modules that it *will* install and
then asks the user for their answers. Thus, when the install actually
begins after the questions have been answered it is fully automatic and
is nicely done "in the background".

This also has the nice side effect that the user can "bail out" in the
quesion phase if the user realizes that he/she does not know some of the
answers.

Have no idea if this was totally off subject. :)

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Andreas.Raab
On 5/18/2010 11:35 PM, Göran Krampe wrote:
> On 05/19/2010 07:44 AM, Andreas Raab wrote:
>> Feedback welcome! Patches even more :-)
>
> I haven't even looked yet - BUT... I got reminded by a nice "feature" in
> Lunar Linux's package management tools when you were discussing "default
> groups" etc. Perhaps I misunderstood - but I guess its about "questions
> to the user when installing stuff".

It's a little off. What I was referring to is that in Metacello you can
define 'groups' of packages. I think the intent is that such groups are
like installation options, e.g., something like

Installing Foo:
   [x] Foo-Core (required group)
   [ ] Foo-Tests (optional group - unit tests)
   [ ] Foo-Help (optional group - documentation)

The current Metacello definition is such that if it exists, the
'default' group is being installed. But that can only be a single group
so in the case that I wanted to structure the above into three separate
groups but by default have both Core and Tests selected I would have to
create a separate default group for that. And that creates confusion
because you can't really present that in a UI properly.

What I'd like to see instead is something where we can define a little
more of the status of these groups. For example: #required (for groups
that must be installed), #default (for groups that are optional, but
installed by default), and #optional (groups that are optional and not
installed by default). The assumption being that the groups are largely
non-overlapping sets of packages that I can independently select. But I
have no idea how Dale intended this to be used so I'll have to wait
until he can comment on this.

> Earlier Installer introduced (Keith IIRC) some mechanism to provide
> automatic answers to regular popup dialogs etc. A hack, but still.

I think this may actually exist in Metacello. I've seen a
'supplyingAnswers:' part of the spec that smelled a lot like that very
hack ;-)

> When you perform an installation of a module the dependency system
> figures out the total list of packages to install - and then compiles a
> *complete* list of questions for all modules that it *will* install and
> then asks the user for their answers. Thus, when the install actually
> begins after the questions have been answered it is fully automatic and
> is nicely done "in the background".

Ah, interesting! Yeah, that's a pretty good idea. So basically the
packages announce beforehand what info they need and later on just use
these answers?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Göran Krampe
On 05/19/2010 10:23 AM, Andreas Raab wrote:

> On 5/18/2010 11:35 PM, Göran Krampe wrote:
>> When you perform an installation of a module the dependency system
>> figures out the total list of packages to install - and then compiles a
>> *complete* list of questions for all modules that it *will* install and
>> then asks the user for their answers. Thus, when the install actually
>> begins after the questions have been answered it is fully automatic and
>> is nicely done "in the background".
>
> Ah, interesting! Yeah, that's a pretty good idea. So basically the
> packages announce beforehand what info they need and later on just use
> these answers?

Yeah. Here is a page describing their system slightly more correctly
than I did:

http://wiki.lunar-linux.org/index.php/Module_Basics

In general I really liked Lunar and its package management - probably
quite similar to BSD ports and Gentoo portage etc, and I do think some
lessons can easily be learned by looking a bit at them.

One interesting trick that Lunar uses (and probably all source distros)
is that when doing the "make install" (or whatever some tar ball wants
to do) phase of a module installation, Lunar first installs low level
filesystem "hooks" to capture ALL modifying file operations performed
during that phase.

This way Lunar always knows EXACTLY what files a certain module actually
did install, and it can then uninstall it cleanly and keep track of
where files "came from".

Now... what would be our counter part? :) A recording Delta can capture
all source modifications, and perhaps the Delta model could be extended
with other "image modification types" like for example - "creation of a
global" or "registry of a service" etc.

Just thinking loud. :)

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Chris Cunnington
In reply to this post by Andreas.Raab
The only thing I don't like about this is a design holdover from the SM Catalog gui: it tells me too much information that I don't actually want. I go to development and I click, and, Hey!, there's the OmniBrowser. That's just what I want! Then I click that, because I'm led by another pointer-arrow. I click that and now ... there are five OmniBrowsers. I don't want five. I'm an end user, not an OB developer. I want THE OB. 

So now I have to scan this list, realize that the highest number is at the bottom (or not, in this mockup), and then suppose that that's the most recent. Select it and then load it. Cross my fingers, and suppose I've understood this interface. Meanwhile, I'm asking myself why the other, outdated, OBs are being given equal billing with the most recent version. 

I have a book on web site design called Don't Make Me Think. This UI makes me have to think and then to guess. The whole direction of Metacello, it seems to me, is to lead people to a series of defaults, so they don't have to think.

I say bury older versions, and present only one version: THE OB, or THE WebClient. If people want to dig into the versions of OB from 1.0 to 1.1.2, then push it out of immediate site. Push it down a level in the hierarchy. 

It's true. I don't lack for opinions. It's been said. :)

Chris 


Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Ralph Johnson
On Wed, May 19, 2010 at 10:08 AM, Chris Cunnington
<[hidden email]> wrote:

> I say bury older versions, and present only one version: THE OB, or THE
> WebClient. If people want to dig into the versions of OB from 1.0 to 1.1.2,
> then push it out of immediate site. Push it down a level in the hierarchy.
> It's true. I don't lack for opinions. It's been said. :)

I agree.  In fact, I don't think that old versions should be in the
image at all.  People who want the old versions should go to the web
site for the package.  The image should just have the current version,
and the browser should only show it.  Otherwise, the system will just
gather more and more cruft.

-Ralph

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Hannes Hirzel
On 5/19/10, Ralph Johnson <[hidden email]> wrote:

> On Wed, May 19, 2010 at 10:08 AM, Chris Cunnington
> <[hidden email]> wrote:
>
>> I say bury older versions, and present only one version: THE OB, or THE
>> WebClient. If people want to dig into the versions of OB from 1.0 to
>> 1.1.2,
>> then push it out of immediate site. Push it down a level in the hierarchy.
>> It's true. I don't lack for opinions. It's been said. :)
>
> I agree.  In fact, I don't think that old versions should be in the
> image at all.  People who want the old versions should go to the web
> site for the package.  The image should just have the current version,
> and the browser should only show it.  Otherwise, the system will just
> gather more and more cruft.
>
> -Ralph
>
>
Absolutely!
It should be easy to load. And the particular version should have been
tested against the particular version of the image I'm actually
working with.

If I want more choice I can always go to check out the Metacello repository.


--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Dale Henrichs
In reply to this post by Andreas.Raab
Andreas Raab wrote:
On 5/18/2010 11:35 PM, Göran Krampe wrote:
  
On 05/19/2010 07:44 AM, Andreas Raab wrote:
    
Feedback welcome! Patches even more :-)
      
I haven't even looked yet - BUT... I got reminded by a nice "feature" in
Lunar Linux's package management tools when you were discussing "default
groups" etc. Perhaps I misunderstood - but I guess its about "questions
to the user when installing stuff".
    

It's a little off. What I was referring to is that in Metacello you can 
define 'groups' of packages. I think the intent is that such groups are 
like installation options, e.g., something like

Installing Foo:
   [x] Foo-Core (required group)
   [ ] Foo-Tests (optional group - unit tests)
   [ ] Foo-Help (optional group - documentation)

The current Metacello definition is such that if it exists, the 
'default' group is being installed. But that can only be a single group 
so in the case that I wanted to structure the above into three separate 
groups but by default have both Core and Tests selected I would have to 
create a separate default group for that. And that creates confusion 
because you can't really present that in a UI properly.
Andreas,

Not sure if this helps or not...

First off one can load more than one target. The #load: method can take a string or a collection of strings, so if the groups 'default', 'Tests' and 'Optional' exist one can specify #('default' 'Tests' 'Optional') as the argument to the load ...

Secondly, metacello takes care of overlap and duplication internally while resolving the list to a set of packages/projects, so you don't have to create groups for all of the possible combinations of groups. In the above you can just add the selected group to the load list...

Dale


Reply | Threaded
Open this post in threaded view
|

Re: Config Browser for Metacello

Dale Henrichs
In reply to this post by Göran Krampe
Göran Krampe wrote:
> One interesting trick that Lunar uses (and probably all source distros)
> is that when doing the "make install" (or whatever some tar ball wants
> to do) phase of a module installation, Lunar first installs low level
> filesystem "hooks" to capture ALL modifying file operations performed
> during that phase.
>
>  
As Andreas noted, there is a supplyingAnswers: spec in Metacello that
allows you to specify the answers to be supplied on a per package basis...

With Metacello, instead of doing a direct #load, you can do a
#fetch/#load. After the #fetch you will have a list of the package  
specs that are scheduled to be loaded, so it is (theoretically) possible
for a tool to run through the supplying answers list and change the
default answers in the configuration, then the modified specs can be
#loaded....

> This way Lunar always knows EXACTLY what files a certain module actually
> did install, and it can then uninstall it cleanly and keep track of
> where files "came from".
>  
Metacello does not keep a data base of installed packages. The image is
the data base ... when you ask a configuration for it's current version,
the current version is calculated based upon  a best match of the
packages installed in the current image and the versions in the
configuration (#versionStatus gives you a measure of the fidelity of the
currentVersion against the existing image). By keeping no state, it is
possible to unload Metatacello and then at a later date reload Metacello
and then do upgrades without having do any data base reconciliation...

In a future version of Metacello I will add the ability to #unload a
configuration (and keeping with the fetch/load idea there will be the
ability to precompute the unload for review by a human or an
algorithm)...I am interested in getting the load half of the equation
resolved before tackling unload ...

Dale