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 |
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 |
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 |
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 |
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 |
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? > > > 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 |
In reply to this post by Damien Cassou
> > 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. > 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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |