Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[philippe.b...@highoctane.be]

What has VTermOutputDriver to do with FilePolicy?

Le 23 oct. 2016 12:22, "stepharo"  a écrit :

> In the bug tracker
>
> https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver
>
> https://pharo.fogbugz.com/f/cases/18649/
>
> we got a lot of problems because the monkey and our build process were
> using the api we wanted to change.
>
> So now we are making the changes one by one.
>
> I hope to work on it during the next sprint.
>
>
> Stef
>
>
>
> Le 23/10/16 à 11:31, p...@highoctane.be a écrit :
>
> Where?
>
> On Sun, Oct 23, 2016 at 10:42 AM, stepharo  wrote:
>
>> Note that all the work on making sure that the image is not writing files
>> when it is on read only mode is part of making coral installable on unix.
>> Now if people wants coral they can join the effort.
>>
>> stef
>>
>>
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[stepharo]

In the bug tracker

https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver

https://pharo.fogbugz.com/f/cases/18649/

we got a lot of problems because the monkey and our build process were 
using the api we wanted to change.


So now we are making the changes one by one.

I hope to work on it during the next sprint.


Stef



Le 23/10/16 à 11:31, p...@highoctane.be a écrit :

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo > wrote:


Note that all the work on making sure that the image is not
writing files
when it is on read only mode is part of making coral installable
on unix.
Now if people wants coral they can join the effort.

stef

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[p...@highoctane.be]

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo  wrote:

> Note that all the work on making sure that the image is not writing files
> when it is on read only mode is part of making coral installable on unix.
> Now if people wants coral they can join the effort.
>
> stef
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[stepharo]

Note that all the work on making sure that the image is not writing files
when it is on read only mode is part of making coral installable on unix.
Now if people wants coral they can join the effort.

stef

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

> On 22 Oct 2016, at 20:16, stepharo  wrote:
> 
> 
> 
> Le 22/10/16 à 17:21, p...@highoctane.be  a écrit :
>> The st command line handler is pretty much giving the same.
>> 
>> I used scale, it works nicely indeed.
>> 
>> But I want Coral reborn.
> 
> me too. 
> Damien is working on a new command line parser. 

we can have one while we want for the other. 
as it is now, we do not have none :)

Esteban 

> 
>> 
>> Phil
>> 
>> On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis > > wrote:
>> This link may interest you command line people , it basically what I 
>> proposed as an idea early on
>> 
>> https://github.com/guillep/Scale 
>> 
>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis > > wrote:
>> I was replying to Thierry saying that we had issues with Pharo mixing 
>> metarepo6 with metarepo5
>> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano > > wrote:
>> 
>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis >> > wrote:
>>> 
>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>> 
>> fixed in what sense?
>> 
>> Esteban
>> 
>> 
> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[stepharo]

Le 22/10/16 à 17:21, p...@highoctane.be a écrit :

The st command line handler is pretty much giving the same.

I used scale, it works nicely indeed.

But I want Coral reborn.


me too.
Damien is working on a new command line parser.



Phil

On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis 
> wrote:


This link may interest you command line people , it basically what
I proposed as an idea early on

https://github.com/guillep/Scale 

On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis
> wrote:

I was replying to Thierry saying that we had issues with Pharo
mixing metarepo6 with metarepo5
On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano
> wrote:



On 22 Oct 2016, at 12:00, Dimitris Chloupis
> wrote:

Didn't Esteban fixed metarepo ? I think I remember him
saying that he did.


fixed in what sense?

Esteban

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

Catalog is a “temporary solution” for a problem that is already 2 years around… 
is not what I would like, and certainly is far from perfect. 
One of this days I will come with a solution that can allow baselines, for 
example…

Esteban

> On 22 Oct 2016, at 18:37, Dale Henrichs  
> wrote:
> 
> I'm wrong ... I hadn't followed the whole chain. Although as I've mentioned 
> in another post, the Catalog is wired to ConfigurationOf and is 
> Pharo-specific ... A common "project load spec" could be plugged into the 
> CatalogBrowser framework and provide ConfigurationOf and BaselineOf support 
> ... 
> 
> Dale
> 
> On 10/22/16 8:31 AM, p...@highoctane.be  wrote:
>> CatalogProvider projectNamed: 'QuickAccess' 
>> 
>> is doing that already.
>> 
>> Or I am mistaken?
>> Phil
>> 
>> On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs 
>> > 
>> wrote:
>> 
>> 
>> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>>> 
 On 22 Oct 2016, at 10:56, Dimitris Chloupis > wrote:
 
 We need some easy to use gem-style installer on the command line.
>>> 
>>> 
>>> we have it: 
>>> 
>>> ./pharo Pharo.image get Seaside3
>>> 
>>> will load seaside into your Pharo.image
>>> 
>>> this is catalog based, of course (there is no magic there, if you want an 
>>> easy way to install things, you need a centralised repository). 
>>> 
>>> Esteban
>>> 
>>> ps: there are a lot of perks like that people ignores… what we actually 
>>> need is a better documentation system :)
>> Esteban,
>> 
>> I really think that the catalog could benefit by a first class objects like 
>> the TDProjectEntry and MetacelloProjectLoadSpec ... these would be objects 
>> directly created and maintained by the project developers themselves. The 
>> objects  would be used for custom build scripts, smalltalkCI builds, catalog 
>> loads, etc. ... oh and if it was a Metacello class, it would be usable cross 
>> platform (Squeak, Pharo, GemStone, etc.)
>> 
>> As a coincidence, I have been planning on talking on this subject at the 
>> upcoming Smalltalks conference ... The working title for the talk is 
>> "Dangerous Liaisons: Smalltalk, Files and Git" ... 
>> 
>> Dale
>> 
> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dale Henrichs]

I'm wrong ... I hadn't followed the whole chain. Although as I've 
mentioned in another post, the Catalog is wired to ConfigurationOf and 
is Pharo-specific ... A common "project load spec" could be plugged into 
the CatalogBrowser framework and provide ConfigurationOf and BaselineOf 
support ...


Dale


On 10/22/16 8:31 AM, p...@highoctane.be wrote:

CatalogProvider projectNamed: 'QuickAccess'

is doing that already.

Or I am mistaken?
Phil

On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs 
> wrote:




On 10/22/16 3:09 AM, Esteban Lorenzano wrote:



On 22 Oct 2016, at 10:56, Dimitris Chloupis
> wrote:

We need some easy to use gem-style installer on the command line.


we have it:

./pharo Pharo.image get Seaside3

will load seaside into your Pharo.image

this is catalog based, of course (there is no magic there, if you
want an easy way to install things, you need a centralised
repository).

Esteban

ps: there are a lot of perks like that people ignores… what we
actually need is a better documentation system :)

Esteban,

I really think that the catalog could benefit by a first class
objects like the TDProjectEntry and MetacelloProjectLoadSpec ...
these would be objects directly created and maintained by the
project developers themselves. The objects  would be used for
custom build scripts, smalltalkCI builds, catalog loads, etc. ...
oh and if it was a Metacello class, it would be usable cross
platform (Squeak, Pharo, GemStone, etc.)

As a coincidence, I have been planning on talking on this subject
at the upcoming Smalltalks conference ... The working title for
the talk is "Dangerous Liaisons: Smalltalk, Files and Git" ...

Dale

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

> On 22 Oct 2016, at 16:24, Norbert Hartl  wrote:
> 
> Isn't that something complementary to pharo. Why have the tools a different 
> name??? I think pharo should be usable as scripting engine. 
> 
> And that means files should begin with
> 
> #! /usr/bin/env pharo
> 
> Norbert

yes, I also suggested them to follow this direction…

Esteban

> 
> Am 22.10.2016 um 13:41 schrieb Esteban Lorenzano  >:
> 
>> 
>>> On 22 Oct 2016, at 12:41, Dimitris Chloupis >> > wrote:
>>> 
>>> This link may interest you command line people , it basically what I 
>>> proposed as an idea early on
>>> 
>>> https://github.com/guillep/Scale 
>> 
>> yes, Santi is working a lot on it so I think they are going to release it 
>> very soon :)
>> 
>> Esteban
>> 
>>> 
>>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis >> > wrote:
>>> I was replying to Thierry saying that we had issues with Pharo mixing 
>>> metarepo6 with metarepo5
>>> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano >> > wrote:
>>> 
 On 22 Oct 2016, at 12:00, Dimitris Chloupis > wrote:
 
 Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>> 
>>> fixed in what sense?
>>> 
>>> Esteban
>>> 
>> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dimitris Chloupis]

Ah ok I see you mean you want a cleaner to do this, I agree, it can be
improved.

On Sat, Oct 22, 2016 at 5:51 PM Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 10/22/16 7:03 AM, Dimitris Chloupis wrote:
>
> Configurations in MetaRepo are supposed to be maintained and uploaded by
> developers anyway. Its a public repo with no requirement for access to
> write and read.
>
> http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60
>
> Unless your solution offers an advantage I cant see.
>
> ConfigurationOfs are "obsolete" ... github projects use BaselineOf and the
> BaselineOf is not portable. The BaselineOf is meant to be loaded from the
> repository that it manages ...
>
> The catalog browser uses the ConfigurationOf to get meta-data about the
> project and then uses the ConfigurationOf to load the project and at the
> moment for a github project to be listed in the catalog one must create a
> ConfigurationOf whose sole purpose is to provide meta data to the catalog.
>
> A MetacelloProjectLoadSpec would provide the portability that a BaselineOf
> lacks, while providing the necessary meta data and maintaining the
> loadability of a ConfigurationOf.
>
>  Finally, a MetacellProjectLoadSpec is useful for more than just the Pharo
> catalog. The same object could be used to load projects in Squeak and
> GemStone and as I have mentioned in the previous email could be a component
> of local build scripts as well ..
>
> So yes I think that there are additional advantages:)
>
>
> Dale
>
>
> On Sat, Oct 22, 2016 at 4:51 PM Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis  wrote:
>
> We need some easy to use gem-style installer on the command line.
>
>
> we have it:
>
> ./pharo Pharo.image get Seaside3
>
> will load seaside into your Pharo.image
>
> this is catalog based, of course (there is no magic there, if you want an
> easy way to install things, you need a centralised repository).
>
> Esteban
>
> ps: there are a lot of perks like that people ignores… what we actually
> need is a better documentation system :)
>
> Esteban,
>
> I really think that the catalog could benefit by a first class objects
> like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be
> objects directly created and maintained by the project developers
> themselves. The objects  would be used for custom build scripts,
> smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello
> class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.)
>
> As a coincidence, I have been planning on talking on this subject at the
> upcoming Smalltalks conference ... The working title for the talk is
> "Dangerous Liaisons: Smalltalk, Files and Git" ...
>
> Dale
>
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[p...@highoctane.be]

CatalogProvider projectNamed: 'QuickAccess'

is doing that already.

Or I am mistaken?
Phil

On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis  wrote:
>
> We need some easy to use gem-style installer on the command line.
>
>
> we have it:
>
> ./pharo Pharo.image get Seaside3
>
> will load seaside into your Pharo.image
>
> this is catalog based, of course (there is no magic there, if you want an
> easy way to install things, you need a centralised repository).
>
> Esteban
>
> ps: there are a lot of perks like that people ignores… what we actually
> need is a better documentation system :)
>
> Esteban,
>
> I really think that the catalog could benefit by a first class objects
> like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be
> objects directly created and maintained by the project developers
> themselves. The objects  would be used for custom build scripts,
> smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello
> class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.)
>
> As a coincidence, I have been planning on talking on this subject at the
> upcoming Smalltalks conference ... The working title for the talk is
> "Dangerous Liaisons: Smalltalk, Files and Git" ...
>
> Dale
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[p...@highoctane.be]

The st command line handler is pretty much giving the same.

I used scale, it works nicely indeed.

But I want Coral reborn.

Phil

On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis 
wrote:

> This link may interest you command line people , it basically what I
> proposed as an idea early on
>
> https://github.com/guillep/Scale
>
> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis 
> wrote:
>
>> I was replying to Thierry saying that we had issues with Pharo mixing
>> metarepo6 with metarepo5
>> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano 
>> wrote:
>>
>>
>> On 22 Oct 2016, at 12:00, Dimitris Chloupis 
>> wrote:
>>
>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>
>>
>> fixed in what sense?
>>
>> Esteban
>>
>>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dale Henrichs]

On 10/22/16 7:03 AM, Dimitris Chloupis wrote:
Configurations in MetaRepo are supposed to be maintained and uploaded 
by developers anyway. Its a public repo with no requirement for access 
to write and read.


http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60 



Unless your solution offers an advantage I cant see.
ConfigurationOfs are "obsolete" ... github projects use BaselineOf and 
the BaselineOf is not portable. The BaselineOf is meant to be loaded 
from the repository that it manages ...


The catalog browser uses the ConfigurationOf to get meta-data about the 
project and then uses the ConfigurationOf to load the project and at the 
moment for a github project to be listed in the catalog one must create 
a ConfigurationOf whose sole purpose is to provide meta data to the catalog.


A MetacelloProjectLoadSpec would provide the portability that a 
BaselineOf lacks, while providing the necessary meta data and 
maintaining the loadability of a ConfigurationOf.


 Finally, a MetacellProjectLoadSpec is useful for more than just the 
Pharo catalog. The same object could be used to load projects in Squeak 
and GemStone and as I have mentioned in the previous email could be a 
component of local build scripts as well ..


So yes I think that there are additional advantages:)

Dale


On Sat, Oct 22, 2016 at 4:51 PM Dale Henrichs 
> wrote:




On 10/22/16 3:09 AM, Esteban Lorenzano wrote:



On 22 Oct 2016, at 10:56, Dimitris Chloupis
> wrote:

We need some easy to use gem-style installer on the command line.


we have it:

./pharo Pharo.image get Seaside3

will load seaside into your Pharo.image

this is catalog based, of course (there is no magic there, if you
want an easy way to install things, you need a centralised
repository).

Esteban

ps: there are a lot of perks like that people ignores… what we
actually need is a better documentation system :)

Esteban,

I really think that the catalog could benefit by a first class
objects like the TDProjectEntry and MetacelloProjectLoadSpec ...
these would be objects directly created and maintained by the
project developers themselves. The objects  would be used for
custom build scripts, smalltalkCI builds, catalog loads, etc. ...
oh and if it was a Metacello class, it would be usable cross
platform (Squeak, Pharo, GemStone, etc.)

As a coincidence, I have been planning on talking on this subject
at the upcoming Smalltalks conference ... The working title for
the talk is "Dangerous Liaisons: Smalltalk, Files and Git" ...

Dale

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Norbert Hartl]

Isn't that something complementary to pharo. Why have the tools a different 
name??? I think pharo should be usable as scripting engine. 

And that means files should begin with

#! /usr/bin/env pharo

Norbert

> Am 22.10.2016 um 13:41 schrieb Esteban Lorenzano :
> 
> 
>> On 22 Oct 2016, at 12:41, Dimitris Chloupis  wrote:
>> 
>> This link may interest you command line people , it basically what I 
>> proposed as an idea early on
>> 
>> https://github.com/guillep/Scale
> 
> yes, Santi is working a lot on it so I think they are going to release it 
> very soon :)
> 
> Esteban
> 
>> 
>>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis  
>>> wrote:
>>> I was replying to Thierry saying that we had issues with Pharo mixing 
>>> metarepo6 with metarepo5
 On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano  
 wrote:
 
 On 22 Oct 2016, at 12:00, Dimitris Chloupis  wrote:
 
 Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>> 
>>> fixed in what sense?
>>> 
>>> Esteban
>>> 
> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dimitris Chloupis]

Configurations in MetaRepo are supposed to be maintained and uploaded by
developers anyway. Its a public repo with no requirement for access to
write and read.

http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60

Unless your solution offers an advantage I cant see.

On Sat, Oct 22, 2016 at 4:51 PM Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis  wrote:
>
> We need some easy to use gem-style installer on the command line.
>
>
> we have it:
>
> ./pharo Pharo.image get Seaside3
>
> will load seaside into your Pharo.image
>
> this is catalog based, of course (there is no magic there, if you want an
> easy way to install things, you need a centralised repository).
>
> Esteban
>
> ps: there are a lot of perks like that people ignores… what we actually
> need is a better documentation system :)
>
> Esteban,
>
> I really think that the catalog could benefit by a first class objects
> like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be
> objects directly created and maintained by the project developers
> themselves. The objects  would be used for custom build scripts,
> smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello
> class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.)
>
> As a coincidence, I have been planning on talking on this subject at the
> upcoming Smalltalks conference ... The working title for the talk is
> "Dangerous Liaisons: Smalltalk, Files and Git" ...
>
> Dale
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dale Henrichs]

On 10/22/16 3:09 AM, Esteban Lorenzano wrote:


On 22 Oct 2016, at 10:56, Dimitris Chloupis > wrote:


We need some easy to use gem-style installer on the command line.


we have it:

./pharo Pharo.image get Seaside3

will load seaside into your Pharo.image

this is catalog based, of course (there is no magic there, if you want 
an easy way to install things, you need a centralised repository).


Esteban

ps: there are a lot of perks like that people ignores… what we 
actually need is a better documentation system :)

Esteban,

I really think that the catalog could benefit by a first class objects 
like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be 
objects directly created and maintained by the project developers 
themselves. The objects  would be used for custom build scripts, 
smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello 
class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.)


As a coincidence, I have been planning on talking on this subject at the 
upcoming Smalltalks conference ... The working title for the talk is 
"Dangerous Liaisons: Smalltalk, Files and Git" ...


Dale

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

> On 22 Oct 2016, at 12:41, Dimitris Chloupis  wrote:
> 
> This link may interest you command line people , it basically what I proposed 
> as an idea early on
> 
> https://github.com/guillep/Scale 

yes, Santi is working a lot on it so I think they are going to release it very 
soon :)

Esteban

> 
> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis  > wrote:
> I was replying to Thierry saying that we had issues with Pharo mixing 
> metarepo6 with metarepo5
> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano  > wrote:
> 
>> On 22 Oct 2016, at 12:00, Dimitris Chloupis > > wrote:
>> 
>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
> 
> fixed in what sense?
> 
> Esteban
> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dimitris Chloupis]

This link may interest you command line people , it basically what I
proposed as an idea early on

https://github.com/guillep/Scale

On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis 
wrote:

> I was replying to Thierry saying that we had issues with Pharo mixing
> metarepo6 with metarepo5
> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano 
> wrote:
>
>
> On 22 Oct 2016, at 12:00, Dimitris Chloupis  wrote:
>
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>
>
> fixed in what sense?
>
> Esteban
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dimitris Chloupis]

I was replying to Thierry saying that we had issues with Pharo mixing
metarepo6 with metarepo5
On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano  wrote:

>
> On 22 Oct 2016, at 12:00, Dimitris Chloupis  wrote:
>
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>
>
> fixed in what sense?
>
> Esteban
>
>

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

> On 22 Oct 2016, at 12:00, Dimitris Chloupis  wrote:
> 
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

fixed in what sense?

Esteban

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Esteban Lorenzano]

> On 22 Oct 2016, at 10:56, Dimitris Chloupis  wrote:
> 
> We need some easy to use gem-style installer on the command line.


we have it: 

./pharo Pharo.image get Seaside3

will load seaside into your Pharo.image

this is catalog based, of course (there is no magic there, if you want an easy 
way to install things, you need a centralised repository). 

Esteban

ps: there are a lot of perks like that people ignores… what we actually need is 
a better documentation system :)

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Dimitris Chloupis]

Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

Don't know how heavy and complex your setup is but if I was in a situation
where the building process became to complex with several builds at the
same time , I think as Phil said a CI would have been more handy. Its what
we use for a vast array of custom images. Obviously you could make your own
command line tool with Pharo. An image dedicated to building your own
images , you alias the Pharo executable passed the image name to any name
that make it look as if it is a bash command or bash utility.

For example

Pharo-build gitfiletree ./filetree -replace -stable -runTests

On Sat, 22 Oct 2016 at 12:34, Thierry Goubier 
wrote:

> Hi Kilon,
>
> 2016-10-22 10:56 GMT+02:00 Dimitris Chloupis :
>
> it depends, the power that pharo offers is just massive on this department.
>
> For example you say you dont like the idea of a global startup script,
> thats fine because you can have startup scripts per image, they go to the
> same folder as your image. If you really have a super complex setup it
> would make sense to make a git repo with just your make file and startup
> scripts. The makefile can be parameterized with command line arguments to
> perform diffirent installs then its a just a matter of copying the correct
> startup script to the folder with the appropriate image which of course is
> something the makefile can handle too.
>
>
> Good point: the Makefile has to copy the startup script inside the image
> directory, if we keep that convention of building the new image inside a
> dedicated directory to be able to clean by rm -r that directory.
>
>
>
> Mariano has a great post on the subject of startup scripts which what I
> used to make my own
>
>
> https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/
>
> By interactive mode again , I assume here you mean the GUI. Again it
> depends what you want to do, a pharo install comes with 2 executables
> pharo-ui which is the well known gui front and pharo which has no gui. In
> both cases you have debug abilities though I presume it would be easier to
> do this from inside a GUI. pharo and pharo-ui has an eval argument that
> allow you to execute any kind of code and there is also a save argument to
> save the image with your new code.
>
>
> Yes. I've been using eval in Makefiles for a few years now. I even prefer
> an eval Metacello new baseline: ... to the command line configuration
> loader, because I can use the standard Smalltalk syntax with eval (and
> Metacello) whereas I need to read the doc for the configuration command
> line handler.
>
> I even have a 'deployment' version for external partners, where the
> Makefile detect it is started from an archive extracted from git and not
> the original git repo, and switches to filetree (and loading different
> packages) to build the image.
>
>
>
> If you prefer GUI then you dont even need to pass metacello arguments,
> just make a configuration installing all your dependencies and put it in
> the STHUB metarepo corresponing to the version of pharo you use, it will be
> available from Package browser and you will be able to install all your
> dependencies with a single click every time you download a new install of
> pharo. Or just install a tool that you can use from playground to install
> the dependencies with a simple message. Or make a spec GUI or morphic GUI
> and do all that from the comfort of your mouse. OR...
>
> the options are just endless.
>
>
> Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and
> Pharo6, as one of the user of the GitFileTree configuration discovered a
> week or two ago. If you are using Pharo5, a configuration in the Pharo6
> metarepo will override the one in the Pharo5 metarepo.
>
>
>
> Another thing to remember here is that a baseline does not have to have
> one setup, you can have multiple setups installing things under diffirent
> conditions. Baseline also are aware of smalltalk implementation (squeak/
> pharo) and pharo versions. That means diffirent installs under diffirent
> conditions and some deep fine tuning. Baseline also allow for actions
> before the install after the install, so even if you want to do some clean
> up you can do this also from the comfort of baseline.
>
> Lastly but not least metacello is fully aware of git branches that gives
> you even more possibilities since a branch even in the same repo can be a
> completely new repo that gives you even more crazy options , since you can
> have diffirent Baseline under diffirent branch and of course the branch can
> contain its own code and assets (images, sounds , binary files, anything).
>
>
> Yes,
>
> Thierry
>
>
>
> It really comes down to the way you like to work, pharo can do it, you
> choose how and what.
>
> On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
> Hi Kilon,
>
> 

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

[Thierry Goubier]

Hi Kilon,

2016-10-22 10:56 GMT+02:00 Dimitris Chloupis :

> it depends, the power that pharo offers is just massive on this department.
>
> For example you say you dont like the idea of a global startup script,
> thats fine because you can have startup scripts per image, they go to the
> same folder as your image. If you really have a super complex setup it
> would make sense to make a git repo with just your make file and startup
> scripts. The makefile can be parameterized with command line arguments to
> perform diffirent installs then its a just a matter of copying the correct
> startup script to the folder with the appropriate image which of course is
> something the makefile can handle too.
>

Good point: the Makefile has to copy the startup script inside the image
directory, if we keep that convention of building the new image inside a
dedicated directory to be able to clean by rm -r that directory.


>
> Mariano has a great post on the subject of startup scripts which what I
> used to make my own
>
> https://marianopeck.wordpress.com/2012/05/12/startuploader-
> running-startup-scripts-in-pharo/
>
> By interactive mode again , I assume here you mean the GUI. Again it
> depends what you want to do, a pharo install comes with 2 executables
> pharo-ui which is the well known gui front and pharo which has no gui. In
> both cases you have debug abilities though I presume it would be easier to
> do this from inside a GUI. pharo and pharo-ui has an eval argument that
> allow you to execute any kind of code and there is also a save argument to
> save the image with your new code.
>

Yes. I've been using eval in Makefiles for a few years now. I even prefer
an eval Metacello new baseline: ... to the command line configuration
loader, because I can use the standard Smalltalk syntax with eval (and
Metacello) whereas I need to read the doc for the configuration command
line handler.

I even have a 'deployment' version for external partners, where the
Makefile detect it is started from an archive extracted from git and not
the original git repo, and switches to filetree (and loading different
packages) to build the image.


>
> If you prefer GUI then you dont even need to pass metacello arguments,
> just make a configuration installing all your dependencies and put it in
> the STHUB metarepo corresponing to the version of pharo you use, it will be
> available from Package browser and you will be able to install all your
> dependencies with a single click every time you download a new install of
> pharo. Or just install a tool that you can use from playground to install
> the dependencies with a simple message. Or make a spec GUI or morphic GUI
> and do all that from the comfort of your mouse. OR...
>
> the options are just endless.
>

Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and
Pharo6, as one of the user of the GitFileTree configuration discovered a
week or two ago. If you are using Pharo5, a configuration in the Pharo6
metarepo will override the one in the Pharo5 metarepo.


>
> Another thing to remember here is that a baseline does not have to have
> one setup, you can have multiple setups installing things under diffirent
> conditions. Baseline also are aware of smalltalk implementation (squeak/
> pharo) and pharo versions. That means diffirent installs under diffirent
> conditions and some deep fine tuning. Baseline also allow for actions
> before the install after the install, so even if you want to do some clean
> up you can do this also from the comfort of baseline.
>
> Lastly but not least metacello is fully aware of git branches that gives
> you even more possibilities since a branch even in the same repo can be a
> completely new repo that gives you even more crazy options , since you can
> have diffirent Baseline under diffirent branch and of course the branch can
> contain its own code and assets (images, sounds , binary files, anything).
>

Yes,

Thierry


>
> It really comes down to the way you like to work, pharo can do it, you
> choose how and what.
>
> On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Kilon,
>>
>> 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis :
>>
>> Actually we dont, I am using the terminal to get and build my own images.
>> Curl + use of startup scripts are more than enough. Simply , easy and
>> straightforward. Pharo offers a super easy way to export any method as a
>> command line argument. So there is literally no excuse.
>>
>> Pharo already offers a metacello argument so you are set to go on
>> installing anything you want through the terminal in your image and also
>> offers evaluation of smalltalk code as argument. But I prefer startup
>> scripts, I have made a startup script that can detect the name of images
>> and install different packages to them, you can do insane things with
>> startup scripts actually.
>>
>>
>> Yes, that looks pretty cool.