On 30/11/15 10:36, Richard Ipsum wrote:
I got a little time to experiment with moving repo aliases into
motivated by the apparent confusion they cause.
As I understand it, the repo-alias field exists so that the chunk repo
fields are 'relocatable' easily.
This is useful in a few cases. In particular, if you have your own Trove
you can set 'trove-host = my-trove.wherever'
in morph.conf and Morph will look for all the Gits on your Trove instead
of on git.baserock.org
However, the 'repo-alias' field in morph.conf is implemented in a really
confusing way, so if you have a use case other than the one above, you
will probably get frustrated.
Also, the fact that the default aliases are defined in Morph and YBD's
source code instead of definitions.git means that we can't easily
introduce new ones.
I tried to document the current repo-alias behaviour here:
The idea is to define them in the DEFAULTS file instead of having
baked into morph/ybd.
I think that putting the default repo-aliases into DEFAULTS is an
improvement, but I think it would be good if the build tool still
allowed users to override them easily, as well.
They would look something like,
# Repo aliases
I echo Richard Maw's feelings on this format -- it's not ideal, but it's
a good compromise for now!
The slightly annoying part here is having to maintain backwards
with version 6 and 7, so I want to ask 2 questions.
Firstly I want to know whether people think this is even worth doing,
if people don't think this is worthwhile then I can possibly save
myself a lot of time. :)
Adding a definitions version 8 where default repo aliases live in
DEFAULTS seems a really good idea.
Secondly I want to know whether people think it would be acceptable
drop support for version 6 and 7 and ask folks to migrate to 8.
I think it *might* be okay to do this (because we don't have a lot of users
right now) but I am not certain, dropping the backwards compatibility here
allows me to remove code instead of adding it, but as we know LOC isn't
My opinion is we should never drop the current support that Morph has
for overriding the repo-aliases. So this question becomes irrelevant I
That said, I always think we should try to have a release of the
reference systems containing a version of Morph that can build the new
definitions format, before dropping support for the old definitions
format. I think that's the minimum compatibility we can offer, if we
expect users to run the build tool inside of the reference systems.
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575