About Pharo working packages

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

About Pharo working packages

Stéphane Ducasse
Hi all

About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
I was wondering if it would not be better to use the Universe mechanism.
We could create a Pharo Universe and people could describe that their  
packages load in Pharo1.0
This would be great and important to get a update to date catalog of  
what is working in Pharo1.0.
What do you think?

Stef





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Miguel Cobá
On Thu, Aug 20, 2009 at 3:32 AM, Stéphane
Ducasse<[hidden email]> wrote:
> Hi all
>
> About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
> I was wondering if it would not be better to use the Universe mechanism.
> We could create a Pharo Universe and people could describe that their
> packages load in Pharo1.0
> This would be great and important to get a update to date catalog of
> what is working in Pharo1.0.
> What do you think?


I think that this will be discussed by the community at a large. What
will be the way to
install packages on Pharo.

SqueakMap (PharoMap)
SqueakSouce (PharoSource)
Monticello repos on other site
Update stream (this will be for the core anyway)
MC1.5, MC1.6, MC2
DeltaStreams
SARs

A lot of options but we must not replicate the nightmare that squeak has.

I personally vote for Monticello and Monticello configuration for a
_well know official repo_.

This repo will have just the official versions that work/worked with
pharo in a given time.
The other versions should be stored on personal separated repos, like
lukas repo or squeak repo.

But let discuss this.

Also, I have something against universes, as they force to use just
the universe versions of a package and don't play
well with separated packages installed from monticello or other (but
maybe it is just me that haven't learned to use it
well, so if this is so, discard this last part)


Miguel Cobá
http://miguel.leugim.com.mx

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Stéphane Ducasse

On Aug 20, 2009, at 7:02 PM, Miguel Cobá wrote:

> On Thu, Aug 20, 2009 at 3:32 AM, Stéphane
> Ducasse<[hidden email]> wrote:
>> Hi all
>>
>> About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
>> I was wondering if it would not be better to use the Universe  
>> mechanism.
>> We could create a Pharo Universe and people could describe that their
>> packages load in Pharo1.0
>> This would be great and important to get a update to date catalog of
>> what is working in Pharo1.0.
>> What do you think?
>
>
> I think that this will be discussed by the community at a large. What
> will be the way to
> install packages on Pharo.

so far
        we only want MC packages :)

> SqueakMap (PharoMap)
> SqueakSouce (PharoSource)
> Monticello repos on other site
> Update stream (this will be for the core anyway)
> MC1.5, MC1.6, MC2
> DeltaStreams
> SARs
>
> A lot of options but we must not replicate the nightmare that squeak  
> has.
>
> I personally vote for Monticello and Monticello configuration for a
> _well know official repo_.
>
> This repo will have just the official versions that work/worked with
> pharo in a given time.
> The other versions should be stored on personal separated repos, like
> lukas repo or squeak repo.

could be a solution
        Pharo10 with all the packages working.

> But let discuss this.
        the problem is that for packages evolving you would have a lot of
traffic

> Also, I have something against universes, as they force to use just
> the universe versions of a package and don't play
> well with separated packages installed from monticello or other (but
> maybe it is just me that haven't learned to use it
> well, so if this is so, discard this last part)

I do not know. I wanted to avoid squeakmap attitude where you could  
not know if a package would load
or not.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Damien Cassou
In reply to this post by Stéphane Ducasse
On Thu, Aug 20, 2009 at 10:32 AM, Stéphane
Ducasse<[hidden email]> wrote:
> About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
> I was wondering if it would not be better to use the Universe mechanism.
> We could create a Pharo Universe and people could describe that their
> packages load in Pharo1.0
> This would be great and important to get a update to date catalog of
> what is working in Pharo1.0.
> What do you think?

For a simple solution, I would propose to provide a class with Pharo
to contain a script per method, each script installing a package,
i.e., like we currently do in ScriptLoader but in another class. This
is similar to what Keith's Packages support already, but without the
Sake syntax and implementation that nobody looked at as of now.

A method could look like:

omnibrowser
  self installer lukas
          project: 'omnibrowser';
          install: 'OmniBrowser';
          install: 'OB-Standard';
          install: 'OB-Morphic';
          install: 'OB-SUnitIntegration'.

The installer used could be either Installer or something else.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Stéphane Ducasse
could be a nice solution with gofer


STef

On Aug 20, 2009, at 7:52 PM, Damien Cassou wrote:

> On Thu, Aug 20, 2009 at 10:32 AM, Stéphane
> Ducasse<[hidden email]> wrote:
>> About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
>> I was wondering if it would not be better to use the Universe  
>> mechanism.
>> We could create a Pharo Universe and people could describe that their
>> packages load in Pharo1.0
>> This would be great and important to get a update to date catalog of
>> what is working in Pharo1.0.
>> What do you think?
>
> For a simple solution, I would propose to provide a class with Pharo
> to contain a script per method, each script installing a package,
> i.e., like we currently do in ScriptLoader but in another class. This
> is similar to what Keith's Packages support already, but without the
> Sake syntax and implementation that nobody looked at as of now.
>
> A method could look like:
>
> omnibrowser
>  self installer lukas
>          project: 'omnibrowser';
>  install: 'OmniBrowser';
>  install: 'OB-Standard';
>  install: 'OB-Morphic';
>  install: 'OB-SUnitIntegration'.
>
> The installer used could be either Installer or something else.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

csrabak
In reply to this post by Miguel Cobá

Em 20/08/2009 14:02, Miguel Cobá < [hidden email] > escreveu:


On Thu, Aug 20, 2009 at 3:32 AM, Stéphane
Ducasse wrote:
> Hi all
>
> About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo
> I was wondering if it would not be better to use the Universe mechanism.
> We could create a Pharo Universe and people could describe that their
> packages load in Pharo1.0
> This would be great and important to get a update to date catalog of
> what is working in Pharo1.0.
> What do you think?

Em 20/08/2009 14:02, Miguel Cobá < [hidden email] > escreveu:


>
> On Thu, Aug 20, 2009 at 3:32 AM, Stéphane Ducasse wrote:
> > Hi all
> >
> > About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo I
> > was wondering if it would not be better to use the Universe
> > mechanism.   We could create a Pharo Universe and people could
> > describe that their packages load in Pharo1.0 This would be great
> > and important to get a update to date catalog of what is working in
> > Pharo1.0.  What do you think?
>
>
> I think that this will be discussed by the community at a large. What
> will be the way to install packages on Pharo.
>
> SqueakMap (PharoMap)
> SqueakSouce (PharoSource)
> Monticello repos on other site
> Update stream (this will be for the core anyway)
> MC1.5, MC1.6, MC2
> DeltaStreams
> SARs

>
> A lot of options but we must not replicate the nightmare that squeak
> has.
>

Yes! We have to make it simple in order to have all
documentation, examples, coordination on packages, etc. always
aligned.

> I personally vote for Monticello and Mont icello configuration for a
> _well know official repo_.
>

Will the forthcoming version of Monticello be able to deal with
changesets and deal automatically with dependencies (like
Universe)?

> This repo will have just the official versions that work/worked with
> pharo in a given time.  The other versions should be stored on
> personal separated repos, like lukas repo or squeak repo.
>
> But let discuss this.
>

I agree. If we don't arrive quickly at a 'winner', we can put a
wiki page where each solution and its strengths (understood here
as features) can be tabulated and then we can find what are the
must have, good to have, etc. to choose one (or chose one as
baseline and augment it [for example I remember one of Squeak
versions had a package to connect to SVN servers]).

> Also, I have something against universes, as they force to use just
> the universe versions of a package and don't play well with separated
> packages installed from monticello or other (but maybe it is just me
> that haven't learned to use it well, so if this is so, discard this
> last part)
>

Well, once one solution (for packaging) be decided to use
officially in Pharo, this tends to have less importance.

My 0.019999. . .

--
Cesar Rabak


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

csrabak
In reply to this post by Damien Cassou




Em 20/08/2009 14:52, Damien Cassou < [hidden email] > escreveu:


>
> On Thu, Aug 20, 2009 at 10:32 AM, Stéphane Ducasse wrote:
> > About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo I
> > was wondering if it would not be better to use the Universe
> > mechanism.  We could create a Pharo Universe and people could
> > describe that their packages load in Pharo1.0 This would be great
> > and important to get a update to date catalog of what is working in
> > Pharo1.0.  What do you think?
>
> For a simple solution, I would propose to provide a class with Pharo
> to contain a script per method, each script installing a package,
> i.e., like we currently do in ScriptLoader but in another class. This
> is similar to what Keith's Packages support already, but without the
> Sake syntax and implementation that nobody looked at as of now.
>
> A method could look like:
>
> omnibrowser
> self installer lukas
> project: 'omnibrowser';
> install: 'OmniBrowser';
> install: 'OB-Standard';
> install: 'OB-Morphic';
> install: 'OB-SUnitIntegration'.
>
> The installer used could be either Installer or something else.
>
If the Installer approach is akin the "Software Updates" we've in
Pharo beta, I think some functionality has to put in place to
work in a similar way Monticello or Universe where one can read
the comments on the changes of package to upload.

 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Adrian Lienhard
Please note that we started discussing this topic a week ago. Maybe  
not everybody has read it (or remembers it). We started a wiki page  
[1] to keep track of possible solutions. Please also update that page  
so that we can keep track of the pros and cons of each solution.

If somebody has time, it would be interesting to test out Metacello to  
see how well it would work for our needs. I think it could be a good  
match.

Cheers,
Adrian

[1] http://code.google.com/p/pharo/wiki/PackageManagementSystem


On Aug 20, 2009, at 21:13 , [hidden email] wrote:

>
>
>
> Em 20/08/2009 14:52, Damien Cassou < [hidden email] >  
> escreveu:
> >
> > On Thu, Aug 20, 2009 at 10:32 AM, Stéphane Ducasse wrote:
> > > About http://code.google.com/p/pharo/wiki/PackagesTestedInPharo I
> > > was wondering if it would not be better to use the Universe
> > > mechanism.  We could create a Pharo Universe and people could
> > > describe that their packages load in Pharo1.0 This would be great
> > > and important to get a update to date catalog of what is working  
> in
> > > Pharo1.0.  What do you think?
> >
> > For a simple solution, I would propose to provide a class with Pharo
> > to contain a script per method, each script installing a package,
> > i.e., like we currently do in ScriptLoader but in another class.  
> This
> > is similar to what Keith's Packages support already, but without the
> > Sake syntax and implementation that nobody looked at as of now.
> >
> > A method could look like:
> >
> > omnibrowser
> > self installer lukas
> > project: 'omnibrowser';
> > install: 'OmniBrowser';
> > install: 'OB-Standard';
> > install: 'OB-Morphic';
> > install: 'OB-SUnitIntegration'.
> >
> > The installer used could be either Installer or something else.
> >
> If the Installer approach is akin the "Software Updates" we've in
> Pharo beta, I think some functionality has to put in place to
> work in a similar way Monticello or Universe where one can read
> the comments on the changes of package to upload.
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Damien Cassou
On Fri, Aug 21, 2009 at 9:00 AM, Adrian Lienhard<[hidden email]> wrote:
> If somebody has time, it would be interesting to test out Metacello to
> see how well it would work for our needs. I think it could be a good
> match.

Let's wait for Dale to release the first version.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About Pharo working packages

Stéphane Ducasse
This is on my todo since version 0.7

Stef

On Aug 21, 2009, at 11:37 AM, Damien Cassou wrote:

> On Fri, Aug 21, 2009 at 9:00 AM, Adrian Lienhard<[hidden email]>  
> wrote:
>> If somebody has time, it would be interesting to test out Metacello  
>> to
>> see how well it would work for our needs. I think it could be a good
>> match.
>
> Let's wait for Dale to release the first version.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> 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