Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

Hi Stef

For example, my project can depend on Iceberg using the following
definition:

spec baseline: 'Iceberg' with: [ spec repository:
> 'github://pharo-vcs/iceberg/:' ];


But now suppose my project have one package that depends on Iceberg
"minimal" and other that depends on the "default" group, how do I describe
that in my baseline? Using project:with I can define two different names
for the same dependency but in different version or group. For example, I
could define "Iceberg Minimal" project that loads the "minimal" group and
another "Iceberg Default" that loads the "default"group and then refer to
them by name, right? I would like to know how to do that with projects from
Iceberg (git) that defines only BaselineOf.


On Sat, Dec 30, 2017 at 7:12 PM, Stephane Ducasse 
wrote:

> Hi vitor
>
> I'm sorry but I do not understand your question? can you rephrase it and
> give an example?
>
> Stef
>
> On Sat, Dec 30, 2017 at 10:03 PM, Vitor Medina Cruz 
> wrote:
>
>> Hello Stephane
>>
>> What if I want to define two projects for the same baseline: both
>> pointing to different groups?
>>
>>
>> 
>>  Livre
>> de vírus. www.avg.com
>> .
>>
>> <#m_-6869378333471435460_m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> From a baseline you can refer to a none github configuration
>>>
>>> here is an example from the pillar newpipeline dev branch it shows you
>>> both: dependencies on github projects and smalltalkhub
>>>
>>>
>>> baseline: spec
>>> 
>>> spec
>>> for: #common
>>> do: [ spec blessing: #baseline.
>>> spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'.
>>> spec
>>> baseline: 'OSSubprocess'
>>> with: [ spec
>>> repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ];
>>>
>>>baseline: 'Mustache'
>>>with: [ spec repository: 'github://noha/mustache:v1.0/repository'
>>> ];
>>>
>>> project: 'Cocoon'
>>> with: [ spec
>>> className: #ConfigurationOfCocoon;
>>> versionString: #stable;
>>> repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ];
>>>
>>>project: 'JSON'
>>>with: [ spec
>>>   className: #ConfigurationOfJSON;
>>>   versionString: #stable;
>>>   repository:
>>> 'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ];
>>>
>>>
>>> project: 'LightPhaser'
>>> with: [ spec
>>> className: #ConfigurationOfLightPhaser;
>>> versionString: '1.0.2';
>>> repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ];
>>> project: 'PetitParser'
>>> with: [ spec
>>> className: #ConfigurationOfPetitParser;
>>> versionString: #stable;
>>> loads: #('Tests');
>>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ];
>>> project: 'PetitParserTest'
>>> with: [ spec
>>> className: #ConfigurationOfPetitParser;
>>> versionString: #stable;
>>> loads: #('Tests');
>>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ].
>>> spec
>>> package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ];
>>> package: 'Pillar-Cli-PillarVersion' with: [ spec requires:
>>> #('Pillar-Cli') ];
>>> package: #'Pillar-ExporterAsciiDoc'
>>>
>>>
>>>
>>> On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz 
>>> wrote:
>>> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a
>>> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool
>>> integration
>>> >> e.g. only Configs show up in the catalog. IIUC, one additional
>>> constraint
>>> >> to
>>> >> be aware of (not sure how important it is in practice) is that in the
>>> past
>>> >> with mcz repos, one could refer to a specific version of each
>>> package, but
>>> >> now you would only be able to specify a version for the whole git
>>> repo.
>>> >
>>> >
>>> > I was about to ask that after reading through Metacello docs — While I
>>> find
>>> > usefull to define groups and dependencies at package level (I need only
>>> > package A from ThatProject on version 2.6, cool!), I didn't understand
>>> why
>>> > define version at package level If many dependencies exists to
>>> different
>>> > versions of different packages belonged to the same project, doesn't
>>> that
>>> > means (or is an indicative) that those packages should be separeted in
>>> > different projects? I don't think this constraint will be a problem.
>>> >
>>> >
>>> > On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris <
>>> s...@clipperadams.com>
>>> > wrote:
>>> >>
>>> >> CyrilFerlicot wrote
>>> >> >> Now I got lost
>>> >>
>>> >> A ConfigurationOfXyz was doing two things:
>>> >> 1) Declaring the project structure of packages and their 

Re: [Pharo-users] Iceberg, Git and Package version

[Stephane Ducasse]

Hi vitor

I'm sorry but I do not understand your question? can you rephrase it and
give an example?

Stef

On Sat, Dec 30, 2017 at 10:03 PM, Vitor Medina Cruz 
wrote:

> Hello Stephane
>
> What if I want to define two projects for the same baseline: both pointing
> to different groups?
>
>
> 
>  Livre
> de vírus. www.avg.com
> .
> <#m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse  > wrote:
>
>> From a baseline you can refer to a none github configuration
>>
>> here is an example from the pillar newpipeline dev branch it shows you
>> both: dependencies on github projects and smalltalkhub
>>
>>
>> baseline: spec
>> 
>> spec
>> for: #common
>> do: [ spec blessing: #baseline.
>> spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'.
>> spec
>> baseline: 'OSSubprocess'
>> with: [ spec
>> repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ];
>>
>>baseline: 'Mustache'
>>with: [ spec repository: 'github://noha/mustache:v1.0/repository'
>> ];
>>
>> project: 'Cocoon'
>> with: [ spec
>> className: #ConfigurationOfCocoon;
>> versionString: #stable;
>> repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ];
>>
>>project: 'JSON'
>>with: [ spec
>>   className: #ConfigurationOfJSON;
>>   versionString: #stable;
>>   repository:
>> 'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ];
>>
>>
>> project: 'LightPhaser'
>> with: [ spec
>> className: #ConfigurationOfLightPhaser;
>> versionString: '1.0.2';
>> repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ];
>> project: 'PetitParser'
>> with: [ spec
>> className: #ConfigurationOfPetitParser;
>> versionString: #stable;
>> loads: #('Tests');
>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ];
>> project: 'PetitParserTest'
>> with: [ spec
>> className: #ConfigurationOfPetitParser;
>> versionString: #stable;
>> loads: #('Tests');
>> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ].
>> spec
>> package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ];
>> package: 'Pillar-Cli-PillarVersion' with: [ spec requires:
>> #('Pillar-Cli') ];
>> package: #'Pillar-ExporterAsciiDoc'
>>
>>
>>
>> On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz 
>> wrote:
>> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a
>> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool
>> integration
>> >> e.g. only Configs show up in the catalog. IIUC, one additional
>> constraint
>> >> to
>> >> be aware of (not sure how important it is in practice) is that in the
>> past
>> >> with mcz repos, one could refer to a specific version of each package,
>> but
>> >> now you would only be able to specify a version for the whole git repo.
>> >
>> >
>> > I was about to ask that after reading through Metacello docs — While I
>> find
>> > usefull to define groups and dependencies at package level (I need only
>> > package A from ThatProject on version 2.6, cool!), I didn't understand
>> why
>> > define version at package level If many dependencies exists to
>> different
>> > versions of different packages belonged to the same project, doesn't
>> that
>> > means (or is an indicative) that those packages should be separeted in
>> > different projects? I don't think this constraint will be a problem.
>> >
>> >
>> > On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris <
>> s...@clipperadams.com>
>> > wrote:
>> >>
>> >> CyrilFerlicot wrote
>> >> >> Now I got lost
>> >>
>> >> A ConfigurationOfXyz was doing two things:
>> >> 1) Declaring the project structure of packages and their dependencies
>> in a
>> >> #baselineXyz: method
>> >> 2) Tagging specific sets of package versions with meaning symbolic to
>> the
>> >> project e.g. 1.2 or stable or whatever
>> >>
>> >>
>> >> CyrilFerlicot wrote
>> >> > So, you just need Metacello to manage the dependencies... This is
>> what
>> >> > BaselineOf do. You just manage the dependencies part and
>> >> > not the versionning part that is already managed by git.
>> >>
>> >> A BaselineOfXyz is very similar to what configurations did for #1,
>> with a
>> >> few simplifications (e.g. you don't need to declare the method a
>> >> "baseline"
>> >> or specify a repo because you obviously already know the repo because
>> >> that's
>> >> where you just got the baseline itself)
>> >>
>> >>
>> >> CyrilFerlicot wrote
>> >> > The equivalent of a ConfigurationOf version in now the SHA of a
>> commit
>> >> > or
>> >> > a tag/release
>> >> > of git).
>> >>
>> >> This is mostly true, but ATM you may want to wrap your 

Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

Hello Stephane

What if I want to define two projects for the same baseline: both pointing
to different groups?


Livre
de vírus. www.avg.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse 
wrote:

> From a baseline you can refer to a none github configuration
>
> here is an example from the pillar newpipeline dev branch it shows you
> both: dependencies on github projects and smalltalkhub
>
>
> baseline: spec
> 
> spec
> for: #common
> do: [ spec blessing: #baseline.
> spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'.
> spec
> baseline: 'OSSubprocess'
> with: [ spec
> repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ];
>
>baseline: 'Mustache'
>with: [ spec repository: 'github://noha/mustache:v1.0/repository'
> ];
>
> project: 'Cocoon'
> with: [ spec
> className: #ConfigurationOfCocoon;
> versionString: #stable;
> repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ];
>
>project: 'JSON'
>with: [ spec
>   className: #ConfigurationOfJSON;
>   versionString: #stable;
>   repository:
> 'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ];
>
>
> project: 'LightPhaser'
> with: [ spec
> className: #ConfigurationOfLightPhaser;
> versionString: '1.0.2';
> repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ];
> project: 'PetitParser'
> with: [ spec
> className: #ConfigurationOfPetitParser;
> versionString: #stable;
> loads: #('Tests');
> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ];
> project: 'PetitParserTest'
> with: [ spec
> className: #ConfigurationOfPetitParser;
> versionString: #stable;
> loads: #('Tests');
> repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ].
> spec
> package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ];
> package: 'Pillar-Cli-PillarVersion' with: [ spec requires: #('Pillar-Cli')
> ];
> package: #'Pillar-ExporterAsciiDoc'
>
>
>
> On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz 
> wrote:
> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a
> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
> >> e.g. only Configs show up in the catalog. IIUC, one additional
> constraint
> >> to
> >> be aware of (not sure how important it is in practice) is that in the
> past
> >> with mcz repos, one could refer to a specific version of each package,
> but
> >> now you would only be able to specify a version for the whole git repo.
> >
> >
> > I was about to ask that after reading through Metacello docs — While I
> find
> > usefull to define groups and dependencies at package level (I need only
> > package A from ThatProject on version 2.6, cool!), I didn't understand
> why
> > define version at package level If many dependencies exists to
> different
> > versions of different packages belonged to the same project, doesn't that
> > means (or is an indicative) that those packages should be separeted in
> > different projects? I don't think this constraint will be a problem.
> >
> >
> > On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris <
> s...@clipperadams.com>
> > wrote:
> >>
> >> CyrilFerlicot wrote
> >> >> Now I got lost
> >>
> >> A ConfigurationOfXyz was doing two things:
> >> 1) Declaring the project structure of packages and their dependencies
> in a
> >> #baselineXyz: method
> >> 2) Tagging specific sets of package versions with meaning symbolic to
> the
> >> project e.g. 1.2 or stable or whatever
> >>
> >>
> >> CyrilFerlicot wrote
> >> > So, you just need Metacello to manage the dependencies... This is what
> >> > BaselineOf do. You just manage the dependencies part and
> >> > not the versionning part that is already managed by git.
> >>
> >> A BaselineOfXyz is very similar to what configurations did for #1, with
> a
> >> few simplifications (e.g. you don't need to declare the method a
> >> "baseline"
> >> or specify a repo because you obviously already know the repo because
> >> that's
> >> where you just got the baseline itself)
> >>
> >>
> >> CyrilFerlicot wrote
> >> > The equivalent of a ConfigurationOf version in now the SHA of a commit
> >> > or
> >> > a tag/release
> >> > of git).
> >>
> >> This is mostly true, but ATM you may want to wrap your BaselineOf in a
> >> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
> >> e.g. only Configs show up in the catalog. IIUC, one additional
> constraint
> >> to
> >> be aware of (not sure how important it is in practice) is that in the
> past
> >> with mcz repos, one could refer to a specific version of each package,
> but
> >> now you would only be able 

Re: [Pharo-users] Iceberg, Git and Package version

[Stephane Ducasse]

>From a baseline you can refer to a none github configuration

here is an example from the pillar newpipeline dev branch it shows you
both: dependencies on github projects and smalltalkhub


baseline: spec

spec
for: #common
do: [ spec blessing: #baseline.
spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'.
spec
baseline: 'OSSubprocess'
with: [ spec
repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ];

   baseline: 'Mustache'
   with: [ spec repository: 'github://noha/mustache:v1.0/repository' ];

project: 'Cocoon'
with: [ spec
className: #ConfigurationOfCocoon;
versionString: #stable;
repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ];

   project: 'JSON'
   with: [ spec
  className: #ConfigurationOfJSON;
  versionString: #stable;
  repository:
'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ];


project: 'LightPhaser'
with: [ spec
className: #ConfigurationOfLightPhaser;
versionString: '1.0.2';
repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ];
project: 'PetitParser'
with: [ spec
className: #ConfigurationOfPetitParser;
versionString: #stable;
loads: #('Tests');
repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ];
project: 'PetitParserTest'
with: [ spec
className: #ConfigurationOfPetitParser;
versionString: #stable;
loads: #('Tests');
repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ].
spec
package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ];
package: 'Pillar-Cli-PillarVersion' with: [ spec requires: #('Pillar-Cli') ];
package: #'Pillar-ExporterAsciiDoc'



On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz  wrote:
>> This is mostly true, but ATM you may want to wrap your BaselineOf in a
>> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
>> e.g. only Configs show up in the catalog. IIUC, one additional constraint
>> to
>> be aware of (not sure how important it is in practice) is that in the past
>> with mcz repos, one could refer to a specific version of each package, but
>> now you would only be able to specify a version for the whole git repo.
>
>
> I was about to ask that after reading through Metacello docs — While I find
> usefull to define groups and dependencies at package level (I need only
> package A from ThatProject on version 2.6, cool!), I didn't understand why
> define version at package level If many dependencies exists to different
> versions of different packages belonged to the same project, doesn't that
> means (or is an indicative) that those packages should be separeted in
> different projects? I don't think this constraint will be a problem.
>
>
> On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris 
> wrote:
>>
>> CyrilFerlicot wrote
>> >> Now I got lost
>>
>> A ConfigurationOfXyz was doing two things:
>> 1) Declaring the project structure of packages and their dependencies in a
>> #baselineXyz: method
>> 2) Tagging specific sets of package versions with meaning symbolic to the
>> project e.g. 1.2 or stable or whatever
>>
>>
>> CyrilFerlicot wrote
>> > So, you just need Metacello to manage the dependencies... This is what
>> > BaselineOf do. You just manage the dependencies part and
>> > not the versionning part that is already managed by git.
>>
>> A BaselineOfXyz is very similar to what configurations did for #1, with a
>> few simplifications (e.g. you don't need to declare the method a
>> "baseline"
>> or specify a repo because you obviously already know the repo because
>> that's
>> where you just got the baseline itself)
>>
>>
>> CyrilFerlicot wrote
>> > The equivalent of a ConfigurationOf version in now the SHA of a commit
>> > or
>> > a tag/release
>> > of git).
>>
>> This is mostly true, but ATM you may want to wrap your BaselineOf in a
>> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
>> e.g. only Configs show up in the catalog. IIUC, one additional constraint
>> to
>> be aware of (not sure how important it is in practice) is that in the past
>> with mcz repos, one could refer to a specific version of each package, but
>> now you would only be able to specify a version for the whole git repo.
>>
>> HTH
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>

Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

>
> This is mostly true, but ATM you may want to wrap your BaselineOf in a
> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
> e.g. only Configs show up in the catalog. IIUC, one additional constraint
> to
> be aware of (not sure how important it is in practice) is that in the past
> with mcz repos, one could refer to a specific version of each package, but
> now you would only be able to specify a version for the whole git repo.


I was about to ask that after reading through Metacello docs — While I find
usefull to define groups and dependencies at package level (I need only
package A from ThatProject on version 2.6, cool!), I didn't understand why
define version at package level If many dependencies exists to
different versions of different packages belonged to the same project,
doesn't that means (or is an indicative) that those packages should be
separeted in different projects? I don't think this constraint will be a
problem.


On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris 
wrote:

> CyrilFerlicot wrote
> >> Now I got lost
>
> A ConfigurationOfXyz was doing two things:
> 1) Declaring the project structure of packages and their dependencies in a
> #baselineXyz: method
> 2) Tagging specific sets of package versions with meaning symbolic to the
> project e.g. 1.2 or stable or whatever
>
>
> CyrilFerlicot wrote
> > So, you just need Metacello to manage the dependencies... This is what
> > BaselineOf do. You just manage the dependencies part and
> > not the versionning part that is already managed by git.
>
> A BaselineOfXyz is very similar to what configurations did for #1, with a
> few simplifications (e.g. you don't need to declare the method a "baseline"
> or specify a repo because you obviously already know the repo because
> that's
> where you just got the baseline itself)
>
>
> CyrilFerlicot wrote
> > The equivalent of a ConfigurationOf version in now the SHA of a commit or
> > a tag/release
> > of git).
>
> This is mostly true, but ATM you may want to wrap your BaselineOf in a
> ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration
> e.g. only Configs show up in the catalog. IIUC, one additional constraint
> to
> be aware of (not sure how important it is in practice) is that in the past
> with mcz repos, one could refer to a specific version of each package, but
> now you would only be able to specify a version for the whole git repo.
>
> HTH
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

But what about versioning of my external dependencies (such as other
projects)? I do that on the baseline too?

The idea in the future is to abstract versioning away from git into
Iceberg?

On Thu, Dec 21, 2017 at 11:49 AM, Cyril Ferlicot D. <
cyril.ferli...@gmail.com> wrote:

> On 21/12/2017 14:43, Vitor Medina Cruz wrote:
>
> > Now I got lost, I had understand that a ConfigurationOfXXX is my project
> > definition and that Iceberg is just the Pharo VCS (in substitution of
> > monticello). Iceberg is now my project? How do I configure my
> > dependencies, groups and versions? The Metacello documentation in Deep
> > in Pharo is deprecated for Iceberg?
> >
>
> Hi,
>
> There is two concepts to distinguish:
> - Versionning
> - Dependencies
>
> Monticello is a VCS that does not manage versionning and dependencies.
> So, you need to create a ConfigurationOfXX managing both dependencies
> (via baselines) and versionning (via configurations).
>
> Git is a VCS that manage the versionning of the project. (The equivalent
> of a ConfigurationOf version in now the SHA of a commit or a tag/release
> of git). So, you just need Metacello to manage the dependencies.
>
> This is what BaselineOf do. You just manage the dependencies part and
> not the versionning part that is already managed by git.
>
> > cheers,
> > Vitor
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-users] Iceberg, Git and Package version

[Cyril Ferlicot D.]

On 21/12/2017 14:43, Vitor Medina Cruz wrote:

> Now I got lost, I had understand that a ConfigurationOfXXX is my project
> definition and that Iceberg is just the Pharo VCS (in substitution of
> monticello). Iceberg is now my project? How do I configure my
> dependencies, groups and versions? The Metacello documentation in Deep
> in Pharo is deprecated for Iceberg?
> 

Hi,

There is two concepts to distinguish:
- Versionning
- Dependencies

Monticello is a VCS that does not manage versionning and dependencies.
So, you need to create a ConfigurationOfXX managing both dependencies
(via baselines) and versionning (via configurations).

Git is a VCS that manage the versionning of the project. (The equivalent
of a ConfigurationOf version in now the SHA of a commit or a tag/release
of git). So, you just need Metacello to manage the dependencies.

This is what BaselineOf do. You just manage the dependencies part and
not the versionning part that is already managed by git.

> cheers,
> Vitor


-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

>
> Package versions do not have any sense on iceberg, where what has sense is
> the “project” version. All packages point to a commit in repo.
>

Oh, I suspected that, but was unsure :)

the thing is: you don’t use configurations with iceberg projects, you use
> baselines.
>

Now I got lost, I had understand that a ConfigurationOfXXX is my project
definition and that Iceberg is just the Pharo VCS (in substitution of
monticello). Iceberg is now my project? How do I configure my dependencies,
groups and versions? The Metacello documentation in Deep in Pharo is
deprecated for Iceberg?

cheers,
Vitor


On Thu, Dec 21, 2017 at 9:02 AM, Esteban Lorenzano 
wrote:

>
>
> On 21 Dec 2017, at 11:03, Vitor Medina Cruz  wrote:
>
> Then in a Metacello configuration should I reference the hash git commit
> or a tag in a version method? For example, an extract from Deep in Pharo:
>
> ConfigurationOfCoolToolSet>>version02: spec
>> 
>> spec for: #common do: [
>> spec blessing: #beta.
>> spec
>> package: 'CoolToolSet-Core' with: 'CoolToolSet-Core-AlanJay.1';
>> package: 'CoolToolSet-Tests' with: 'CoolToolSet-Tests-AlanJay.1';
>> project: 'CoolBrowser default' with: '1.3';
>> project: 'CoolBrowser Tests' with: '1.3’].
>>
>
> the thing is: you don’t use configurations with iceberg projects, you use
> baselines.
>
> Esteban
>
>
> In this case  'CoolToolSet-Core-AlanJay.1' would be changed by
> 'CoolToolSet-Core-'?
>
> On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse  > wrote:
>
>> In iceberg you can specify
>> - latest version when you do not specify anything
>> - a version (but it should be a git tag so you should save you code
>> with a tag - iceberg does not support it right now but you can do it
>> with git)
>> - the hash of your git commit.
>>
>> Does it answer your question?
>> Stef
>>
>>
>> On Wed, Dec 20, 2017 at 7:51 PM, Vitor Medina Cruz 
>> wrote:
>> > Hello,
>> >
>> > How are packages versions computed in Iceberg?
>> >
>> > I am looking at the Metacello documentation at 'Deep in Pharo', it says
>> I
>> > can define dependencies at package level and it uses the following
>> format to
>> > identify versions: ; which I think is a pattern
>> used
>> > by Monticello, right? However, I can't figure what is the equivalent (if
>> > any) in Iceberg.
>> >
>> > Thanks in Advance,
>> > Vitor
>>
>>
>
>

Re: [Pharo-users] Iceberg, Git and Package version

[Esteban Lorenzano]

> On 21 Dec 2017, at 11:03, Vitor Medina Cruz  wrote:
> 
> Then in a Metacello configuration should I reference the hash git commit or a 
> tag in a version method? For example, an extract from Deep in Pharo:
> 
> ConfigurationOfCoolToolSet>>version02: spec
> 
> spec for: #common do: [
> spec blessing: #beta.
> spec
> package: 'CoolToolSet-Core' with: 'CoolToolSet-Core-AlanJay.1';
> package: 'CoolToolSet-Tests' with: 'CoolToolSet-Tests-AlanJay.1';
> project: 'CoolBrowser default' with: '1.3';
> project: 'CoolBrowser Tests' with: '1.3’].

the thing is: you don’t use configurations with iceberg projects, you use 
baselines.

Esteban

> 
> In this case  'CoolToolSet-Core-AlanJay.1' would be changed by 
> 'CoolToolSet-Core-'?
> 
> On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse  > wrote:
> In iceberg you can specify
> - latest version when you do not specify anything
> - a version (but it should be a git tag so you should save you code
> with a tag - iceberg does not support it right now but you can do it
> with git)
> - the hash of your git commit.
> 
> Does it answer your question?
> Stef
> 
> 
> On Wed, Dec 20, 2017 at 7:51 PM, Vitor Medina Cruz  > wrote:
> > Hello,
> >
> > How are packages versions computed in Iceberg?
> >
> > I am looking at the Metacello documentation at 'Deep in Pharo', it says I
> > can define dependencies at package level and it uses the following format to
> > identify versions: ; which I think is a pattern used
> > by Monticello, right? However, I can't figure what is the equivalent (if
> > any) in Iceberg.
> >
> > Thanks in Advance,
> > Vitor
> 
> 

Re: [Pharo-users] Iceberg, Git and Package version

[Esteban Lorenzano]

> On 20 Dec 2017, at 19:51, Vitor Medina Cruz  wrote:
> 
> Hello,
> 
> How are packages versions computed in Iceberg? 
> 
> I am looking at the Metacello documentation at 'Deep in Pharo', it says I can 
> define dependencies at package level and it uses the following format to 
> identify versions: ; which I think is a pattern used 
> by Monticello, right? However, I can't figure what is the equivalent (if any) 
> in Iceberg. 
> 
> Thanks in Advance,
> Vitor


Hi Vitor, 

Package versions do not have any sense on iceberg, where what has sense is the 
“project” version. All packages point to a commit in repo.  

This is to say, you do not load single package in iceberg but you load a 
repository version (which is the commit). 
That’s why you use Metacello expressions like this: 

Metacello new 
repository: ‘github://someuser/someproject:sometag' 
;
baseline: ‘Blah’;
load.

and in your baselines, when you include another project you do 

spec 
baseline: ‘Blah’
with: [ spec repository: ‘github://someuser/someproject:sometag' 
 ].

cheers!
Esteban

Re: [Pharo-users] Iceberg, Git and Package version

[Vitor Medina Cruz]

Then in a Metacello configuration should I reference the hash git commit or
a tag in a version method? For example, an extract from Deep in Pharo:

ConfigurationOfCoolToolSet>>version02: spec
> 
> spec for: #common do: [
> spec blessing: #beta.
> spec
> package: 'CoolToolSet-Core' with: 'CoolToolSet-Core-AlanJay.1';
> package: 'CoolToolSet-Tests' with: 'CoolToolSet-Tests-AlanJay.1';
> project: 'CoolBrowser default' with: '1.3';
> project: 'CoolBrowser Tests' with: '1.3'].
>

In this case  'CoolToolSet-Core-AlanJay.1' would be changed by
'CoolToolSet-Core-'?

On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse 
wrote:

> In iceberg you can specify
> - latest version when you do not specify anything
> - a version (but it should be a git tag so you should save you code
> with a tag - iceberg does not support it right now but you can do it
> with git)
> - the hash of your git commit.
>
> Does it answer your question?
> Stef
>
>
> On Wed, Dec 20, 2017 at 7:51 PM, Vitor Medina Cruz 
> wrote:
> > Hello,
> >
> > How are packages versions computed in Iceberg?
> >
> > I am looking at the Metacello documentation at 'Deep in Pharo', it says I
> > can define dependencies at package level and it uses the following
> format to
> > identify versions: ; which I think is a pattern
> used
> > by Monticello, right? However, I can't figure what is the equivalent (if
> > any) in Iceberg.
> >
> > Thanks in Advance,
> > Vitor
>
>

Re: [Pharo-users] Iceberg, Git and Package version

[Stephane Ducasse]

In iceberg you can specify
- latest version when you do not specify anything
- a version (but it should be a git tag so you should save you code
with a tag - iceberg does not support it right now but you can do it
with git)
- the hash of your git commit.

Does it answer your question?
Stef


On Wed, Dec 20, 2017 at 7:51 PM, Vitor Medina Cruz  wrote:
> Hello,
>
> How are packages versions computed in Iceberg?
>
> I am looking at the Metacello documentation at 'Deep in Pharo', it says I
> can define dependencies at package level and it uses the following format to
> identify versions: ; which I think is a pattern used
> by Monticello, right? However, I can't figure what is the equivalent (if
> any) in Iceberg.
>
> Thanks in Advance,
> Vitor