[ANN] Gofer Project Loader 1.0 (BETA)

Hi,
I want to announce the immediate release of GoferProjectLoader, a Gofer
extension to manage Metacello configurations.
For all who want to know quickly what is this, here is a small synopsis:

GoferProjectLoader is a loader for Metacello configurations (A
metacello configuration is a full project load tool, including
package/project dependencies with it corresponding versions).
GoferProjectLoader automatically scan projects stored on
MetacelloRepository, but you can add your private repositories as well.
GoferProjectLoader responsibilities include:

1) Install project versions and keep track of them.
2) Update configurations and upgrade projects (if desired).

GoferProjectLoader relies on Metacello and Gofer to perform this tasks
(In fact, It can be thought as a Gofer extension to understand
Metacello packages).

To load GoferProjectLoader, you need to do:

Gofer it
        squeaksource: 'MetacelloRepository';
        package: 'ConfigurationOfGoferProjectLoader';
        load.

ConfigurationOfGoferProjectLoader project lastVersion load.

With this... you'll never need again to perform once and again this
repetitive configuration... instead, you can do things like:

Gofer project
        load: 'Seaside30';
        load: 'Pier2'.

You can see the full documentation here:
http://www.smallworks.com.ar/en/community/GoferProjectLoader

Now I'm working on the promised page for configurations (Adrian: I
really sorry for the delay... I know I promised this a lot of time
ago... but time is the tyrant :( )

Cheers,
Esteban



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

This is so cool! Thank you for pushing this.

Lukas

On 17 March 2010 14:23, Esteban Lorenzano <[hidden email]> wrote:


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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Esteban,

It looks cool. I tried and I was seen apparent problems.
I think it would be useful to add
        loadLastVersionOf:
        loadLastStableVersionOf:

I am not aware of Metacello details, but where is there a distinction  
between loading and upgrading?
You do not have removeProject: or something?

Cheers,
Alexandre


On 17 Mar 2010, at 09:23, Esteban Lorenzano wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Excellent Esteban! Muy buena la idea che!

Thanks!!

2010/3/17 Esteban Lorenzano <[hidden email]>:


--
=================================================
Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=================================================

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Esteban

Looks cool! I haven't had time to test it out in depth yet, but here three questions:

- does it keep memory of which projects are loaded? Is this what you refer to as "managed projects"?
- would it make sense to integrate it into Gofer?
- any idea about how we go to differentiate "stable" and "unstable" universes for each Pharo version? How does the user know which version is the one he needs for his version of Pharo? Sorry, this is not directly related to the Gofer Project Loader but I think it is the next important step towards a working package management system!

Cheers,
Adrian

On Mar 17, 2010, at 14:23 , Esteban Lorenzano wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Alexandre,

load:

...already loads latest stable version, but if the project hasn't any
declared stable version, it will throw a "no stable version found"
error, and you'll need to look for a version (using
#availableVersionsOf:)
of course, this can be improved... I will think on a way to do it.

upgrade

loads new versions of an already present project (if there are newer
versions on a configuration).

and no, I didn't implement a project remove... because metacello
(afaik) doesn't have it, and it was outside the scope of the loader. Of
course, I think it is a very important feature, but it will be added in
the future.

Cheers,
Esteban


On 2010-03-17 11:42:21 -0300, Alexandre Bergel
<[hidden email]> said:




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Adrian,

On 2010-03-17 11:15:10 -0300, Adrian Lienhard
<[hidden email]> said:

> Hi Esteban
>
> Looks cool! I haven't had time to test it out in depth yet, but here
> three questions:
>
> - does it keep memory of which projects are loaded? Is this what you
> refer to as "managed projects"?

Yes, it keeps a list of "managed projects" (with  itself as the first
one) so it can check for new versions, etc.

> - would it make sense to integrate it into Gofer?

I don't know... this is a "mixer" between Gofer and Metacello. If we
integrate it with Gofer core, suddenly we wil be creating a new
dependence package to add to core (Metacello)... of course, Metacello
can be loaded "at first project load" just like now "at first
configuration loaded", but I don't know if this is desirable... your
choice more than mine :)
What will be cool is to include the gofer project loader into PharoDev
distributions.

> - any idea about how we go to differentiate "stable" and "unstable"
> universes for each Pharo version? How does the user know which version
> is the one he needs for his version of Pharo? Sorry, this is not
> directly related to the Gofer Project Loader but I think it is the next
> important step towards a working package management system!

No clue... maybe we need to add to Metacello a new "dependence
dimension", like "minimum version of distribution"... but Dale can be
much more helpful than me in this area.

Cheers,
Esteban



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> -1 to put it in Gofer. In my opinion, it is perfect as it is.
>
> +9999 to put it in PharoDev, but not in 1.0. We can put it when we start
> building PharoDev 1.1

Makes sense

Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Alexandre,
>
> load:
>
> ...already loads latest stable version, but if the project hasn't  
> any declared stable version, it will throw a "no stable version  
> found" error, and you'll need to look for a version (using  
> #availableVersionsOf:)
> of course, this can be improved... I will think on a way to do it.

Excellent!
When you load something, it would be nice to provide some feedback on  
which version is loaded, and which one is available.
I am picky, I know :-)

> upgrade
>
> loads new versions of an already present project (if there are newer  
> versions on a configuration).

But is there a situation where I would prefer an upgrade instead of a  
load?


>
> and no, I didn't implement a project remove... because metacello  
> (afaik) doesn't have it, and it was outside the scope of the loader.  
> Of course, I think it is a very important feature, but it will be  
> added in the future.

Sure, no problem.

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mar 17, 2010, at 4:54 16PM, Alexandre Bergel wrote:

Belongs in complimentary UI / Logging packages, imo.
As long as the ProjectLoader raises appropriate announcements (cough cough), it shouldn't be hard to separate (optional) feedback from the actual loading actions.
>
>> upgrade
>>
>> loads new versions of an already present project (if there are newer versions on a configuration).
>
> But is there a situation where I would prefer an upgrade instead of a load?

It doesn't reinstall if the latest version is already loaded?
Also, if mcd's between two versions were available, it could potentially install much faster :)

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Exactly.
For the MooseLoader, we have a transcript that shows up with the  
relevant information. This is not perfect, but it is useful. Indeed,  
having a set of announcement will definitly be a good move.


Yes, but load: could not check whether the package is already  
installed, and in that case just do an upgrade?

Alexandre

>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

esteban

excellent!!!
Now how can we load code for  Pharo1.0 which is different for Pharo1.1 and soon Pharo1.2....
you see what I mean.

Ideally I would like to have the MetacelloRepository structured in a tree with versions
1.0/1.2.... so that in three years from now I can still load a version of something.
The idea that we discuss with Dale is to be able to to a freeze of a configuration so that it copies
all the dependent packages in a metacelloRepository.

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Excellent work ... very good idea to hook it into Gofer!

Dale
----- "Esteban Lorenzano" <[hidden email]> wrote:

| Hi,
| I want to announce the immediate release of GoferProjectLoader, a
| Gofer
| extension to manage Metacello configurations.
| For all who want to know quickly what is this, here is a small
| synopsis:
|
| GoferProjectLoader is a loader for Metacello configurations (A
| metacello configuration is a full project load tool, including
| package/project dependencies with it corresponding versions).
| GoferProjectLoader automatically scan projects stored on
| MetacelloRepository, but you can add your private repositories as
| well.
| GoferProjectLoader responsibilities include:
|
| 1) Install project versions and keep track of them.
| 2) Update configurations and upgrade projects (if desired).
|
| GoferProjectLoader relies on Metacello and Gofer to perform this tasks
|
| (In fact, It can be thought as a Gofer extension to understand
| Metacello packages).
|
| To load GoferProjectLoader, you need to do:
|
| Gofer it
| squeaksource: 'MetacelloRepository';
| package: 'ConfigurationOfGoferProjectLoader';
| load.
|
| ConfigurationOfGoferProjectLoader project lastVersion load.
|
| With this... you'll never need again to perform once and again this
| repetitive configuration... instead, you can do things like:
|
| Gofer project
| load: 'Seaside30';
| load: 'Pier2'.
|
| You can see the full documentation here:
| http://www.smallworks.com.ar/en/community/GoferProjectLoader
|
| Now I'm working on the promised page for configurations (Adrian: I
| really sorry for the delay... I know I promised this a lot of time
| ago... but time is the tyrant :( )
|
| Cheers,
| Esteban
|
|
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Alexandre,

load involves loading a project into an image in which the project does not exist.
upgrade involves loading a project into an image in which the project already is loaded.

Loading is straightforward ... it is what we do all of the time. Add a bunch of classes and methods, then run the #initialize methods for the new classes.

Upgrading is interesting because besides adding/removing classes and methods, you have to worry about completely unloading packages that are no longer part of the project. You also have to worry about the fact that new classes will get there #initialize methods, but preexisitng classes will not ... which can lead to interesting results. This may lead to pre/post upgrade doits...

Remove is interesting because you have to also consider removing any projects that are dependent upon the project being removed.

Once Metacello 1.0 is released I start working on  adding upgrade and remove to Metacello.

Dale
----- "Alexandre Bergel" <[hidden email]> wrote:

| Hi Esteban,
|
| It looks cool. I tried and I was seen apparent problems.
| I think it would be useful to add
| loadLastVersionOf:
| loadLastStableVersionOf:
|
| I am not aware of Metacello details, but where is there a distinction
|
| between loading and upgrading?
| You do not have removeProject: or something?
|
| Cheers,
| Alexandre
|
|
| On 17 Mar 2010, at 09:23, Esteban Lorenzano wrote:
|
| > Hi,
| > I want to announce the immediate release of GoferProjectLoader, a  
| > Gofer extension to manage Metacello configurations.
| > For all who want to know quickly what is this, here is a small  
| > synopsis:
| >
| > GoferProjectLoader is a loader for Metacello configurations (A  
| > metacello configuration is a full project load tool, including  
| > package/project dependencies with it corresponding versions).  
| > GoferProjectLoader automatically scan projects stored on  
| > MetacelloRepository, but you can add your private repositories as  
| > well. GoferProjectLoader responsibilities include:
| >
| > 1) Install project versions and keep track of them.
| > 2) Update configurations and upgrade projects (if desired).
| >
| > GoferProjectLoader relies on Metacello and Gofer to perform this  
| > tasks (In fact, It can be thought as a Gofer extension to understand
|  
| > Metacello packages).
| >
| > To load GoferProjectLoader, you need to do:
| >
| > Gofer it
| > squeaksource: 'MetacelloRepository';
| > package: 'ConfigurationOfGoferProjectLoader';
| > load.
| >
| > ConfigurationOfGoferProjectLoader project lastVersion load.
| >
| > With this... you'll never need again to perform once and again this
|
| > repetitive configuration... instead, you can do things like:
| >
| > Gofer project
| > load: 'Seaside30';
| > load: 'Pier2'.
| >
| > You can see the full documentation here:
| > http://www.smallworks.com.ar/en/community/GoferProjectLoader
| >
| > Now I'm working on the promised page for configurations (Adrian: I
|
| > really sorry for the delay... I know I promised this a lot of time
|
| > ago... but time is the tyrant :( )
| >
| > Cheers,
| > Esteban
| >
| >
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [hidden email]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| --
| _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| Alexandre Bergel  http://www.bergel.eu
| ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
|
|
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I easily understand the difference. I was just wondering whether load:  
cannot do an update: if the package is present already. Maybe as I  
user I should not take care whether a package is already present  
before loading it. Just a thought.

> Remove is interesting because you have to also consider removing any  
> projects that are dependent upon the project being removed.
>
> Once Metacello 1.0 is released I start working on  adding upgrade  
> and remove to Metacello.

Sounds like a good plan!
Thanks for your explanation.

Alexandre


--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

----- "Esteban Lorenzano" <[hidden email]> wrote:

| > - any idea about how we go to differentiate "stable" and "unstable"
|
| > universes for each Pharo version? How does the user know which version
| > is the one he needs for his version of Pharo? Sorry, this is not
| > directly related to the Gofer Project Loader but I think it is the next
| > important step towards a working package management system!
|
| No clue... maybe we need to add to Metacello a new "dependence
| dimension", like "minimum version of distribution"... but Dale can be
| much more helpful than me in this area.

I imagine that code targetted for specific Pharo versions will be treated like we treat code targeted for different Smalltalk dialects. So you would write specs  like the following:

        spec for: #common do: [...].
        spec for: #squeakCommon do: [...].
        spec for: #pharo do: [...].
        spec for: #'pharo1.0' do: [...].
        spec for: #'pharo1.1' do: [...].

or possibly like the following, if a finer version granularity is needed:

        spec for: #common do: [...].
        spec for: #squeakCommon do: [...].
        spec for: #pharo do: [...].
        spec for: #'pharo1.0' do: [...].
        spec for: #'pharo1.0-10508' do: [...].
        spec for: #'pharo1.0-10515' do: [...].
        spec for: #'pharo1.1' do: [...].
        spec for: #'pharo1.1-11508' do: [...].
        spec for: #'pharo1.1-11515' do: [...].

Dale

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

----- "Alexandre Bergel" <[hidden email]> wrote:

| > load involves loading a project into an image in which the project
| > does not exist.
| > upgrade involves loading a project into an image in which the  
| > project already is loaded.
| >
| > Loading is straightforward ... it is what we do all of the time. Add
| > a bunch of classes and methods, then run the #initialize methods for
| > the new classes.
| >
| > Upgrading is interesting because besides adding/removing classes and
| > methods, you have to worry about completely unloading packages that
| > are no longer part of the project. You also have to worry about the
| > fact that new classes will get there #initialize methods, but  
| > preexisitng classes will not ... which can lead to interesting  
| > results. This may lead to pre/post upgrade doits...
|
| I easily understand the difference. I was just wondering whether load:
| cannot do an update: if the package is present already. Maybe as I  
| user I should not take care whether a package is already present  
| before loading it. Just a thought.

That is probably a good idea ... the less someone has to think before running a script the better, as long as the 'right thing is done'.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

----- "Stéphane Ducasse" <[hidden email]> wrote:

| esteban
|
| excellent!!!
| Now how can we load code for  Pharo1.0 which is different for Pharo1.1
| and soon Pharo1.2....
| you see what I mean.
|
| Ideally I would like to have the MetacelloRepository structured in a
| tree with versions
| 1.0/1.2.... so that in three years from now I can still load a version
| of something.
| The idea that we discuss with Dale is to be able to to a freeze of a
| configuration so that it copies
| all the dependent packages in a metacelloRepository.

Metacello 1.0-beta.25 will have a couple of new features that support the creation and use of historical/secondary repositories.

I have added #fetch/#fetch: that downloads all of the packages/configurations into a target repository ... the using #repositoryOverrides: you can arrange that all of the package loads will done from the target repository (regardless of what the config specifies)...

Dale

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project