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
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 <vitormcruz@gmail.com> 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
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 <stepharo.self@gmail.com> 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 <vitormcruz@gmail.com> 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
On 21 Dec 2017, at 11:03, Vitor Medina Cruz <vitormcruz@gmail.com> 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 <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> 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 <vitormcruz@gmail.com <mailto:vitormcruz@gmail.com>> 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
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 <estebanlm@gmail.com> wrote:
On 21 Dec 2017, at 11:03, Vitor Medina Cruz <vitormcruz@gmail.com> 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 <stepharo.self@gmail.com
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 <vitormcruz@gmail.com> 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
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
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
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 <sean@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 to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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 <vitormcruz@gmail.com> 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 <sean@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 to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hello Stephane What if I want to define two projects for the same baseline: both pointing to different groups? <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <stepharo.self@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 <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 <vitormcruz@gmail.com> 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 < sean@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 to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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 <vitormcruz@gmail.com> wrote:
Hello Stephane
What if I want to define two projects for the same baseline: both pointing to different groups?
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...>. <#m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <stepharo.self@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 <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 <vitormcruz@gmail.com> 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 < sean@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 to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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 <stepharo.self@gmail.com> 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 <vitormcruz@gmail.com> wrote:
Hello Stephane
What if I want to define two projects for the same baseline: both pointing to different groups?
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...>.
<#m_-6869378333471435460_m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse < stepharo.self@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 <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 <vitormcruz@gmail.com> 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 < sean@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 to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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.ferlicot@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
On 20 Dec 2017, at 19:51, Vitor Medina Cruz <vitormcruz@gmail.com> 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: âgithub://someuser/someproject:sometag' <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' <github://someuser/someproject:sometag'> ]. cheers! Esteban
participants (5)
-
Cyril Ferlicot D. -
Esteban Lorenzano -
Sean P. DeNigris -
Stephane Ducasse -
Vitor Medina Cruz