Smalltalk › Pharo › Pharo Smalltalk Users

Iceberg, Git and Package version

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Vitor Medina Cruz

Iceberg, Git and Package version

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: <dev_name.versionNumber>; 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

Stephane Ducasse-3

Re: Iceberg, Git and Package version

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 <[hidden email]> 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: <dev_name.versionNumber>; 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

Vitor Medina Cruz

Re: Iceberg, Git and Package version

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
<version: '0.2' imports: #('0.2-baseline' )>
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-<git_hash>'?

On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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: <dev_name.versionNumber>; 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

EstebanLM

Re: Iceberg, Git and Package version

In reply to this post by Vitor Medina Cruz

On 20 Dec 2017, at 19:51, Vitor Medina Cruz <[hidden email]> 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: <dev_name.versionNumber>; 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: ‘<a href="github://someuser/someproject:sometag'" class="">github://someuser/someproject:sometag';

baseline: ‘Blah’;

load.

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

spec

baseline: ‘Blah’

with: [ spec repository: ‘<a href="github://someuser/someproject:sometag'" class="">github://someuser/someproject:sometag' ].

cheers!

Esteban

EstebanLM

Re: Iceberg, Git and Package version

In reply to this post by Vitor Medina Cruz

On 21 Dec 2017, at 11:03, Vitor Medina Cruz <[hidden email]> 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
<version: '0.2' imports: #('0.2-baseline' )>
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-<git_hash>'?

On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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: <dev_name.versionNumber>; 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

Vitor Medina Cruz

Re: Iceberg, Git and Package version

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 <[hidden email]> wrote:

On 21 Dec 2017, at 11:03, Vitor Medina Cruz <[hidden email]> 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
<version: '0.2' imports: #('0.2-baseline' )>
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-<git_hash>'?

On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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: <dev_name.versionNumber>; 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

CyrilFerlicot

Re: Iceberg, Git and Package version

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

Sean P. DeNigris

Re: Iceberg, Git and Package version

Administrator

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

Cheers,
Sean

Vitor Medina Cruz

Re: Iceberg, Git and Package version

In reply to this post by CyrilFerlicot

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. <[hidden email]> 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

Vitor Medina Cruz

Re: Iceberg, Git and Package version

In reply to this post by Sean P. DeNigris

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 <[hidden email]> 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

Stephane Ducasse-3

Re: Iceberg, Git and Package version

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
<baseline>
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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>

Vitor Medina Cruz

Re: Iceberg, Git and Package version

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.

On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <[hidden email]> 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
<baseline>
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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>

Stephane Ducasse-3

Re: Iceberg, Git and Package version

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 <[hidden email]> 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.

On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <[hidden email]> 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
<baseline>
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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>

Vitor Medina Cruz

Re: Iceberg, Git and Package version

Hi Stef

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

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

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 <[hidden email]> 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 <[hidden email]> 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.

On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <[hidden email]> 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
<baseline>
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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>