How to load a baseline in Iceberg? Get #addTo: sent to nil?
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it). Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ. In trying to debug the code I can see its trying to find a handler for gitlocal:/// <gitlocal:///>, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)? Iâm wondering how other people are loading their projects in Iceberg if this doesnât work? Tim
Answering a portion of my own question - enabling the Metacello Integration setting, does get a bit further, but then it expects my BaselineOF package to have a project method (which I guess configurationOF packages have) - but as this is a baseline I didnât think it was supposed to have one of these? So I guess that setting isnât applicable? Tim
On 2 Aug 2017, at 22:31, Tim Mackinnon <tim@testit.works> wrote:
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ.
In trying to debug the code I can see its trying to find a handler for gitlocal:/// <gitlocal:///>, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)?
Iâm wondering how other people are loading their projects in Iceberg if this doesnât work?
Tim
What is the Metacello integration setting? Esteban A. Maringolo 2017-08-02 19:01 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Answering a portion of my own question - enabling the Metacello Integration setting, does get a bit further, but then it expects my BaselineOF package to have a project method (which I guess configurationOF packages have) - but as this is a baseline I didnât think it was supposed to have one of these?
So I guess that setting isnât applicable?
Tim
On 2 Aug 2017, at 22:31, Tim Mackinnon <tim@testit.works> wrote:
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)?
Iâm wondering how other people are loading their projects in Iceberg if this doesnât work?
Tim
Its in the settings options under Iceberg - It looks like it offloads some loading to Metacello vs handling it directly in Iceberg - but have not seen many people talk about it. I'm still curious how people are loading things as I've realised I've probably had this issue all along but didn't realise it, until I found a very simple example of it. Tim Sent from my iPhone
On 3 Aug 2017, at 01:55, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
What is the Metacello integration setting?
Esteban A. Maringolo
2017-08-02 19:01 GMT-03:00 Tim Mackinnon <tim@testit.works>:
Answering a portion of my own question - enabling the Metacello Integration setting, does get a bit further, but then it expects my BaselineOF package to have a project method (which I guess configurationOF packages have) - but as this is a baseline I didnât think it was supposed to have one of these?
So I guess that setting isnât applicable?
Tim
On 2 Aug 2017, at 22:31, Tim Mackinnon <tim@testit.works> wrote:
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)?
Iâm wondering how other people are loading their projects in Iceberg if this doesnât work?
Tim
This works for me (to load BaselineOfTowergame from src/ relative to image location): | hereRef | hereRef := Smalltalk imageDirectory asFileReference. "Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@'). (IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register. IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access" Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'. Towergame configure. Smalltalk snapshot: true andQuit: true. You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access). Tim Mackinnon wrote:
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)?
Iâm wondering how other people are loading their projects in Iceberg if this doesnât work?
Tim
It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasnât properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think). Iâm just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange). I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (thatâs why there is an install menu item just on baselineOF packages?) Tim
On 3 Aug 2017, at 09:09, Herby VojÄÃk <herby@mailbox.sk> wrote:
This works for me (to load BaselineOfTowergame from src/ relative to image location):
| hereRef | hereRef := Smalltalk imageDirectory asFileReference.
"Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@').
(IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register.
IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access"
Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'.
Towergame configure.
Smalltalk snapshot: true andQuit: true.
You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access).
Tim Mackinnon wrote:
Iâm wondering if Iâm missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I donât need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the âinstall baseline (default)â option, I was expecting it to load both packages for me - however I get the talkback error â#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: methodâ.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesnât find one and then tries to create a repo and bails⦠this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - âEnable Metacello Integrationâ - should I set that to true (its false by default)?
Iâm wondering how other people are loading their projects in Iceberg if this doesnât work?
Tim
Hi Tim, On Thu, Aug 03, 2017 at 10:55:09AM +0100, Tim Mackinnon wrote:
It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasn???t properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think).
I???m just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange).
I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (that???s why there is an install menu item just on baselineOF packages?)
I don't know the original intent, but I've never thought about Iceberg this way. My understanding is that baselineOf: is intended for use by metacello. Iceberg allows you to load individual packages, but it's focus area is code development, not package loading. I use Iceberg to load the baseline package, edit it, then save it back to the git repository, then load the entire project through metacello (usually in separate images so I'm testing in a clean environment). HTH, Alistair
Tim
On 3 Aug 2017, at 09:09, Herby Voj????k <herby@mailbox.sk> wrote:
This works for me (to load BaselineOfTowergame from src/ relative to image location):
| hereRef | hereRef := Smalltalk imageDirectory asFileReference.
"Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@').
(IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register.
IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access"
Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'.
Towergame configure.
Smalltalk snapshot: true andQuit: true.
You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access).
Tim Mackinnon wrote:
I???m wondering if I???m missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I don???t need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the ???install baseline (default)??? option, I was expecting it to load both packages for me - however I get the talkback error ???#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: method???.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesn???t find one and then tries to create a repo and bails??? this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - ???Enable Metacello Integration??? - should I set that to true (its false by default)?
I???m wondering how other people are loading their projects in Iceberg if this doesn???t work?
Tim
Alistair - does that mean youâve not tried using that menu item on a baseline package? I think its there for this reason - but maybe Esteban will comment when heâs back from holiday. So on a related front - do you go to a separate workspace and type in Metacello new baseline: âMyBaseline'; repository: 'filetree://./local-project/src'; load. ? I have tried loading all the packages in iceberg and then tried to load them with a script like this (but its very awkward - and I hadnât thought of just using the Metacello variant) BaselineOfLambda project version spec packageSpecsInLoadOrder allButLast do: [ :s | s version load ].
On 3 Aug 2017, at 14:15, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Tim,
On Thu, Aug 03, 2017 at 10:55:09AM +0100, Tim Mackinnon wrote:
It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasn???t properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think).
I???m just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange).
I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (that???s why there is an install menu item just on baselineOF packages?)
I don't know the original intent, but I've never thought about Iceberg this way.
My understanding is that baselineOf: is intended for use by metacello. Iceberg allows you to load individual packages, but it's focus area is code development, not package loading.
I use Iceberg to load the baseline package, edit it, then save it back to the git repository, then load the entire project through metacello (usually in separate images so I'm testing in a clean environment).
HTH, Alistair
Tim
On 3 Aug 2017, at 09:09, Herby Voj????k <herby@mailbox.sk> wrote:
This works for me (to load BaselineOfTowergame from src/ relative to image location):
| hereRef | hereRef := Smalltalk imageDirectory asFileReference.
"Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@').
(IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register.
IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access"
Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'.
Towergame configure.
Smalltalk snapshot: true andQuit: true.
You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access).
Tim Mackinnon wrote:
I???m wondering if I???m missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I don???t need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the ???install baseline (default)??? option, I was expecting it to load both packages for me - however I get the talkback error ???#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: method???.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesn???t find one and then tries to create a repo and bails??? this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - ???Enable Metacello Integration??? - should I set that to true (its false by default)?
I???m wondering how other people are loading their projects in Iceberg if this doesn???t work?
Tim
On Thu, Aug 03, 2017 at 05:28:33PM +0100, Tim Mackinnon wrote:
Alistair - does that mean you?ve not tried using that menu item on a baseline package? I think its there for this reason - but maybe Esteban will comment when he?s back from holiday.
OK, that's embarrassing... I didn't read your email properly, and no, I hadn't tried it. The error occurs when Iceberg's metacello integration is disabled. So if you execute: Iceberg enableMetacelloIntegration: true. And then load the baseline, it will work, although Iceberg doesn't refresh its display properly. Can you open a fogbugz issue on the error case?
So on a related front - do you go to a separate workspace and type in
Metacello new baseline: ?MyBaseline'; repository: 'filetree://./local-project/src'; load.
?
Yep, but normally in a completely separate image so that it is a clean environment. I normally have a script that loads all the required packages, so I can just: pharo-ui Pharo.image load_all.st In the development environment (where I'm using Iceberg) everything is loaded, so I'm just testing the package functionality, not loading the packages. Cheers, Alistair
I have tried loading all the packages in iceberg and then tried to load them with a script like this (but its very awkward - and I hadn?t thought of just using the Metacello variant)
BaselineOfLambda project version spec packageSpecsInLoadOrder allButLast do: [ :s | s version load ].
On 3 Aug 2017, at 14:15, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Tim,
On Thu, Aug 03, 2017 at 10:55:09AM +0100, Tim Mackinnon wrote:
It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasn???t properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think).
I???m just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange).
I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (that???s why there is an install menu item just on baselineOF packages?)
I don't know the original intent, but I've never thought about Iceberg this way.
My understanding is that baselineOf: is intended for use by metacello. Iceberg allows you to load individual packages, but it's focus area is code development, not package loading.
I use Iceberg to load the baseline package, edit it, then save it back to the git repository, then load the entire project through metacello (usually in separate images so I'm testing in a clean environment).
HTH, Alistair
Tim
On 3 Aug 2017, at 09:09, Herby Voj????k <herby@mailbox.sk> wrote:
This works for me (to load BaselineOfTowergame from src/ relative to image location):
| hereRef | hereRef := Smalltalk imageDirectory asFileReference.
"Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@').
(IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register.
IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access"
Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'.
Towergame configure.
Smalltalk snapshot: true andQuit: true.
You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access).
Tim Mackinnon wrote:
I???m wondering if I???m missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I don???t need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the ??? install baseline (default)??? option, I was expecting it to load both packages for me - however I get the talkback error ???#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: method???.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesn???t find one and then tries to create a repo and bails??? this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - ???Enable Metacello Integration??? - should I set that to true (its false by default)?
I???m wondering how other people are loading their projects in Iceberg if this doesn???t work?
Tim
So I dont think I am going crazy - but there are so many different ways of working. I'll raise a bug in the morning. The trouble with enabling metacello support is that baselines aren't configs and so they don't have methods like #project that it seems to rely on. Tim Sent from my iPhone
On 3 Aug 2017, at 20:29, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Aug 03, 2017 at 05:28:33PM +0100, Tim Mackinnon wrote: Alistair - does that mean you?ve not tried using that menu item on a baseline package? I think its there for this reason - but maybe Esteban will comment when he?s back from holiday.
OK, that's embarrassing... I didn't read your email properly, and no, I hadn't tried it.
The error occurs when Iceberg's metacello integration is disabled. So if you execute:
Iceberg enableMetacelloIntegration: true.
And then load the baseline, it will work, although Iceberg doesn't refresh its display properly.
Can you open a fogbugz issue on the error case?
So on a related front - do you go to a separate workspace and type in
Metacello new baseline: ?MyBaseline'; repository: 'filetree://./local-project/src'; load.
?
Yep, but normally in a completely separate image so that it is a clean environment. I normally have a script that loads all the required packages, so I can just:
pharo-ui Pharo.image load_all.st
In the development environment (where I'm using Iceberg) everything is loaded, so I'm just testing the package functionality, not loading the packages.
Cheers, Alistair
I have tried loading all the packages in iceberg and then tried to load them with a script like this (but its very awkward - and I hadn?t thought of just using the Metacello variant)
BaselineOfLambda project version spec packageSpecsInLoadOrder allButLast do: [ :s | s version load ].
On 3 Aug 2017, at 14:15, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Tim,
On Thu, Aug 03, 2017 at 10:55:09AM +0100, Tim Mackinnon wrote:
It might be something in this area - I will have to study. I am using gitlab and have done a clone - so the packages are on my disk, but it did look like it wasn???t properly finding them due to the naming of the local git url (so not quite your issue, but in a similar space I think).
I???m just surprised no-one else is mentioning this which makes me wonder if its my setup (although this is a vanilla zeroconf with nothing strange).
I think you are supposed to be able to clone, then click on a baselineOf package and pick install - and this should get all your code into the image (that???s why there is an install menu item just on baselineOF packages?)
I don't know the original intent, but I've never thought about Iceberg this way.
My understanding is that baselineOf: is intended for use by metacello. Iceberg allows you to load individual packages, but it's focus area is code development, not package loading.
I use Iceberg to load the baseline package, edit it, then save it back to the git repository, then load the entire project through metacello (usually in separate images so I'm testing in a clean environment).
HTH, Alistair
Tim
On 3 Aug 2017, at 09:09, Herby Voj????k <herby@mailbox.sk> wrote:
This works for me (to load BaselineOfTowergame from src/ relative to image location):
| hereRef | hereRef := Smalltalk imageDirectory asFileReference.
"Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@').
(IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register.
IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access"
Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load: 'development'.
Towergame configure.
Smalltalk snapshot: true andQuit: true.
You may not need the workarounds (first is for non-"git@" remote, second is for github:// not working without a github.com ssh access).
Tim Mackinnon wrote:
I???m wondering if I???m missing a trick somewhere - but I have a simple project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I don???t need the BaseLineOf, but I was learning how to use them and I simply added a postLoad hook to run some code in it).
Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. If I right click on the BaseLine one, and click the ??? install baseline (default)??? option, I was expecting it to load both packages for me - however I get the talkback error ???#addTo: was sent to nil from the MCRepositoryGroup>>addRepository: method???.
In trying to debug the code I can see its trying to find a handler for gitlocal:///, doesn???t find one and then tries to create a repo and bails??? this seems like a bug? I did notice in tracing the code that there is a reference to a Setting that I saw - ???Enable Metacello Integration??? - should I set that to true (its false by default)?
I???m wondering how other people are loading their projects in Iceberg if this doesn???t work?
Tim
participants (4)
-
Alistair Grant -
Esteban A. Maringolo -
Herby VojÄÃk -
Tim Mackinnon