Iceberg + BaselinOf + Metacello - how to manage interdependencies ?
Hi all, Iâm trying to declare a BaselinOf to load lots of Packages. My aim is to have a kind of distribution (so students donât have to load packages). Iâm new to Iceberg + BaselinOf + Metacello. I target only P7. Let's say I want to load Teapot and NeoJSON (development version). Teapot depends on NeoJSON (#stable). So, whatever the order of declaration in the BaselineOfMyProject, Iâd like not to have the following conflict: So is it possible to tell to load : - Teapot , then NeoJSON (updating to NeoJSON the dependancies of Teapot) - NeoJSON (#latest) then Teapot (ignoring the NeoJSON stable of Teapot baseline). I know I risk breaking Teapot (but I donât care :), I want latest NeoJSON. So is it possible to define such constraints ? Iâm aware of that way of loading from Metacello : Metacello new baseline: 'NeoCSV'; repository: 'gitlocal://../../iceberg/svenvc/NeoCSV' ; onConflict: [ :err | err useIncoming ]; onUpgrade: [ :err | err useIncoming ]; load Still, not sure, of the meaning of #useIncoming (#allow #disallow). 1) Does one mean keep/load the latest ? 2) is it possible to launch such Metacello installation from Iceberg ? TIA, Cédrick
Nobody knows ? I probably do/ask something wrong⦠My impression is that it is very difficult for a newcomer to get into Iceberg/Github (I tried to avoid GIT as much as possible and I understand why now ^_^)⦠but still itâs a great tool. Just not that easy to "master" (there are several possibilities, orders for code loading). Please tell me if there is something wrong in what I try to do. Cheers, Cédrick
Iâm trying to declare a BaselinOf to load lots of Packages. My aim is to have a kind of distribution (so students donât have to load packages). Iâm new to Iceberg + BaselinOf + Metacello. I target only P7.
Let's say I want to load Teapot and NeoJSON (development version). Teapot depends on NeoJSON (#stable).
So, whatever the order of declaration in the BaselineOfMyProject, Iâd like not to have the following conflict:
<unknown.png>
So is it possible to tell to load :
- Teapot , then NeoJSON (updating to NeoJSON the dependancies of Teapot) - NeoJSON (#latest) then Teapot (ignoring the NeoJSON stable of Teapot baseline).
I know I risk breaking Teapot (but I donât care :), I want latest NeoJSON.
So is it possible to define such constraints ?
Iâm aware of that way of loading from Metacello :
Metacello new baseline: 'NeoCSV'; repository: 'gitlocal://../../iceberg/svenvc/NeoCSV <gitlocal://../iceberg/svenvc/NeoCSV>' ; onConflict: [ :err | err useIncoming ]; onUpgrade: [ :err | err useIncoming ]; load Still, not sure, of the meaning of #useIncoming (#allow #disallow). 1) Does one mean keep/load the latest ? 2) is it possible to launch such Metacello installation from Iceberg ? <PastedGraphic-2.png>
TIA,
Cédrick
Hi, You are not alone. I have the same impression that Metacello+Git+Iceberg is something very difficult to grasp. It is getting hard to keep the pace with a constant evolving Pharo system. best ichi -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Ichi, If you are learning Pharo I suggest you to not follow this way for now as it may result in cognitive overload and frustration. If you just want to save your code on some repo, use Metacello to create a tonel repository, then do code revision the way you use to do it (command line, third party GUI application). Your workflow will be: 1. Create a tonel report from Monticello: click on '+Repository' and chose tonel://, then select the direcotory in your host to save the code. 2. On this repo do Add to package to add your code (hope it works in released P7, does not on my Pharo7.0-32bit-0c5ade3). 2. Do the code versioning in the way you use to do it and with the tool you want. (git, svn, bzr, CLI, GUI) 3. Each time you want to save code change, go to Monticello and save dirty package 4. make the commit with your versioning system Hilaire Le 01/12/2018 à 12:10, Ichiseki a écrit :
Hi, You are not alone. I have the same impression that Metacello+Git+Iceberg is something very difficult to grasp. It is getting hard to keep the pace with a constant evolving Pharo system. best ichi
-- Dr. Geo http://drgeo.eu
On 2 Dec 2018, at 11:31, Hilaire <hilaire@drgeo.eu> wrote:
Hi Ichi,
If you are learning Pharo I suggest you to not follow this way for now as it may result in cognitive overload and frustration.
Although the workflow described below does indeed work, it (1) assumes you already know how to handle a classic VCS on the command line (2) does not give you elementary diff tools in the IDE that understand your programming language So I don't think it is 'the (better) way to go'. In my experience, using Iceberg in the image, combined with the GitHub Web UI and the git command line tools, works really well, once you 'get' it. Yes, there is a learning curve as with anything.
If you just want to save your code on some repo, use Metacello to create a tonel repository, then do code revision the way you use to do it (command line, third party GUI application).
Your workflow will be:
1. Create a tonel report from Monticello: click on '+Repository' and chose tonel://, then select the direcotory in your host to save the code.
2. On this repo do Add to package to add your code (hope it works in released P7, does not on my Pharo7.0-32bit-0c5ade3).
2. Do the code versioning in the way you use to do it and with the tool you want. (git, svn, bzr, CLI, GUI)
3. Each time you want to save code change, go to Monticello and save dirty package
4. make the commit with your versioning system
Hilaire
Le 01/12/2018 à 12:10, Ichiseki a écrit :
Hi, You are not alone. I have the same impression that Metacello+Git+Iceberg is something very difficult to grasp. It is getting hard to keep the pace with a constant evolving Pharo system. best ichi
-- Dr. Geo http://drgeo.eu
On 2 Dec 2018, at 12:00, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Dec 2018, at 11:31, Hilaire <hilaire@drgeo.eu> wrote:
Hi Ichi,
If you are learning Pharo I suggest you to not follow this way for now as it may result in cognitive overload and frustration.
Although the workflow described below does indeed work, it
(1) assumes you already know how to handle a classic VCS on the command line (2) does not give you elementary diff tools in the IDE that understand your programming language
So I don't think it is 'the (better) way to go'.
In my experience, using Iceberg in the image, combined with the GitHub Web UI and the git command line tools, works really well, once you 'get' it. Yes, there is a learning curve as with anything.
Yes, as Sven said, Hilaireâs approach can work better for people that already knows Monticello, and because of that they are initially more confortable with it. Today, I would suggest you to start with iceberg: declare your project, add your packages and do commits/pushs from there. Yes, you need some insight of what is git and how it work. But Iâd argue thatâs something you will need with anything :) Esteban
If you just want to save your code on some repo, use Metacello to create a tonel repository, then do code revision the way you use to do it (command line, third party GUI application).
Your workflow will be:
1. Create a tonel report from Monticello: click on '+Repository' and chose tonel://, then select the direcotory in your host to save the code.
2. On this repo do Add to package to add your code (hope it works in released P7, does not on my Pharo7.0-32bit-0c5ade3).
2. Do the code versioning in the way you use to do it and with the tool you want. (git, svn, bzr, CLI, GUI)
3. Each time you want to save code change, go to Monticello and save dirty package
4. make the commit with your versioning system
Hilaire
Le 01/12/2018 à 12:10, Ichiseki a écrit :
Hi, You are not alone. I have the same impression that Metacello+Git+Iceberg is something very difficult to grasp. It is getting hard to keep the pace with a constant evolving Pharo system. best ichi
-- Dr. Geo http://drgeo.eu
cedreek wrote
So is it possible to define such constraints ?
IIUC you could use #onConflict: and be more specific in the block as to allow only the specific case you mentioned, but I think the more common approach is to use the Metacello API to "lock" NeoJSON to the version you want. I don't have an image handy, but search either the Pharo or Metacello MLs for "API lock" or something cedreek wrote
Still, not sure, of the meaning of #useIncoming (#allow #disallow).
Browse MetacelloResolveProjectUpgrade. There are several synonyms for the same action. IIRC #allow et all means continue to load replacing the currently loaded version, #disallow means use the version already loaded. cedreek wrote
2) is it possible to launch such Metacello installation from Iceberg ?
I don't see why you couldn't put the API lock into a preloadDoit in your baseline A context shift is definitely required to get a handle on this, but after the initial investment, it's pretty straightforward. There are a few concepts applied repeatedly in most common cases. Hang in there! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hello, Thank you Sean :)
So is it possible to define such constraints ?
IIUC you could use #onConflict: and be more specific in the block as to allow only the specific case you mentioned, but I think the more common approach is to use the Metacello API to "lock" NeoJSON to the version you want. I don't have an image handy, but search either the Pharo or Metacello MLs for "API lock" or something
Yep. This is what I try to do right now. I think my « mistake » was to see BaselineOf as a Metacello script⦠Iâm getting (slowly) a better understanding of all that. I put a halt in the onConglict but couldnât get what I wantâ¦.
cedreek wrote
Still, not sure, of the meaning of #useIncoming (#allow #disallow).
Browse MetacelloResolveProjectUpgrade. There are several synonyms for the same action. IIRC #allow et all means continue to load replacing the currently loaded version, #disallow means use the version already loaded.
Yes but still, if I understand correctly, it will depend on my load order. I was looking for something like #useNewestVersion (but this might not be possible with DVCS anywayâ¦) So maybe #useLatestFromOfficialRepo I hope you see what I mean :) I might declare what I consider as official repo (like GitHub/svenvc, pharo-extra/polymath, etcâ¦). Anyway, I will try to do it with available possibilities so donât worry about that. Just trying to express my need and use case. Hope it makes sense a bit. Once Iâve s baseline working (or a Metacello script), next action is to do a Jenkins CI job. Any doc/pointers on that ?
cedreek wrote
2) is it possible to launch such Metacello installation from Iceberg ?
I don't see why you couldn't put the API lock into a preloadDoit in your baseline
I need to learn more this preloadDoIt.
A context shift is definitely required to get a handle on this, but after the initial investment, it's pretty straightforward. There are a few concepts applied repeatedly in most common cases. Hang in there!
Yes I think so too⦠Anyway, Iâm not at all criticising Iceberg/Metacello, I really find these tools excellent and a huge improvement :) really cool to see all these GitHub account and smalltalk code. So I continue to learn :) To give an idea of what I want, see the joined pic (and I tried to restrain myself not loading too many cool packages ^_^). I also decided to create baseline subclasses to manage windows and unixes distributions. Cheers, Cédrick
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (6)
-
Cédrick Béler -
Esteban Lorenzano -
Hilaire -
Ichiseki -
Sean P. DeNigris -
Sven Van Caekenberghe