Smalltalk › Frameworks & Tools › Monticello, Metacello ... › Metacello

override repositories (again)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

EstebanLM

override repositories (again)

Hi,

Some time ago I asked for a way to override repositories, as a way to deal with the fact that projects can have different structures (for example work with submodules or not).
So, I has this configuration:

load: ProjA
load: ProjB

or this other one:

load: ProjA (with submodule ProjB)

Now I have another case in which it would be useful: I want to work on a cloned repository.
For example, I have

github.com/tide-framework/etc.

and I want to work with my cloned repository:

github.com/estebanlm/etc.

... of course, a description like this:

baseline: spec
<baseline>

spec for: #pharo do: [
spec repository: 'github://tide-framework/marina:master'.

self tide: spec.
self pillar: spec.
self voyage: spec.
self xmlWriter: spec.

spec package: 'Marina' with: [
spec requires: #('Tide' 'Pillar' 'Voyage' 'XMLWriter') ] ]

will not work for me.
Of course, I can replace the string for a message and then have setters and default.
But then I cannot use:

Metacello new
configuration: 'Marina';
version: #development;
repository: 'github://tide-framework/marina:master';
load.

as a way to load.
I would want to be able to say:

Metacello new
configuration: 'Marina';
version: #development;
repository: 'github://estebanlm/marina:master';
load.

and have an automatic "default repository"... which is the one I set.

So. Is this reasonable?
Shouldn't we incorporate this?
Otherwise, I find it very limiting :(

Esteban

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dale Henrichs-3

Re: override repositories (again)

Esteban,

This is the use case for Metacello locks[1].

In a nutshell you evaluate the following in your image:

Metacello new
configuration: 'Marina';
version: #development;
repository: 'github://estebanlm/marina:master';
lock.

and from that point onward, when you load a project that references Marina, Marina will be loaded from the github://estebanlm/marina:master repository. You can use the `lock` command without actually loading Marina into your image.

Depending upon which version of Metacello you are using, you may have to add an `onConflict:` clause to your load expression:

Metacello new

configuration: 'Tide';

version: #development;

repository: 'whaterver';

onConflict: [:ex | ex disallow]; "disallow 'honors' the lock, and allow 'breaks' the lock"

load.

In the latest version of Metacello, honoring a lock is the default behavior (a Waring message is written to the transcript) and an `onLock:` clause has been added so you can write:

Metacello new

configuration: 'Tide';

version: #development;

repository: 'whaterver';

onLock: [:ex | ex break ]; "honor can be used to honor the lock ... but that's the default"

load.

Be aware that you are using a "hybrid configuration" (I assume) that is a configuration that references a baseline ... I've been fighting different bugs related to hybrid configurations and I think I've got them all licked with Metacello Preview 1.0-beta.32.14....but I don't think that this version has been integrated into Pharo3.0.

I'm not able to test Metacello against Pharo3.0 for quite awhile, so I can only assume that Metacello Preview 1.0-beta.32.14 will work in Pharo3.0 (it passes on all other Pharo versions)...

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md

On Thu, Jul 24, 2014 at 5:05 AM, Esteban Lorenzano <[hidden email]> wrote:

Hi,

Some time ago I asked for a way to override repositories, as a way to deal with the fact that projects can have different structures (for example work with submodules or not).
So, I has this configuration:

load: ProjA
load: ProjB

or this other one:

load: ProjA (with submodule ProjB)

Now I have another case in which it would be useful: I want to work on a cloned repository.
For example, I have

github.com/tide-framework/etc.

and I want to work with my cloned repository:

github.com/estebanlm/etc.

... of course, a description like this:

baseline: spec
<baseline>

spec for: #pharo do: [
spec repository: 'github://tide-framework/marina:master'.

self tide: spec.
self pillar: spec.
self voyage: spec.
self xmlWriter: spec.

spec package: 'Marina' with: [
spec requires: #('Tide' 'Pillar' 'Voyage' 'XMLWriter') ] ]

will not work for me.
Of course, I can replace the string for a message and then have setters and default.
But then I cannot use:

Metacello new
configuration: 'Marina';
version: #development;
repository: 'github://tide-framework/marina:master';
load.

as a way to load.
I would want to be able to say:

Metacello new
configuration: 'Marina';
version: #development;
repository: 'github://estebanlm/marina:master';
load.

and have an automatic "default repository"... which is the one I set.

So. Is this reasonable?
Shouldn't we incorporate this?
Otherwise, I find it very limiting :(

Esteban

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.