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