IRC logs for #baserock for Friday, 2015-12-04

*** richard_maw has quit IRC04:48
*** richard_maw has joined #baserock04:48
*** ChanServ sets mode: +v richard_maw04:48
*** tristan has joined #baserock06:04
*** tristan is now known as Guest615706:05
*** Guest6157 is now known as gtristan06:06
*** gtristan has quit IRC06:13
*** gtristan has joined #baserock06:14
*** gtristan has quit IRC06:22
*** gtristan has joined #baserock06:28
*** gtristan has quit IRC07:17
*** gtristan has joined #baserock07:18
*** gtristan has quit IRC07:41
*** gtristan has joined #baserock07:41
*** CTtpollard has quit IRC08:35
*** CTtpollard has joined #baserock08:41
*** locallycompact has joined #baserock08:41
*** bashrc_ has joined #baserock09:07
*** edcragg has joined #baserock09:15
*** tiagogomes has joined #baserock09:29
*** franred has joined #baserock09:41
*** jonathanmaw has joined #baserock10:02
*** ssam2 has joined #baserock10:04
*** ChanServ sets mode: +v ssam210:04
*** rdale has joined #baserock10:08
*** rdale_ct_ has quit IRC10:10
*** CTtpollard has quit IRC10:11
*** ssam2 has quit IRC10:13
*** bjdooks has quit IRC10:13
*** bjdooks has joined #baserock10:19
*** Lachlan1975 has joined #baserock10:22
*** ssam2 has joined #baserock10:25
*** ChanServ sets mode: +v ssam210:25
*** CTtpollard has joined #baserock10:26
*** gtristan has quit IRC10:41
*** gtristan has joined #baserock11:14
*** nowster has quit IRC13:05
*** franred has quit IRC13:06
*** franred has joined #baserock13:19
*** nowster has joined #baserock13:20
*** edcragg has quit IRC13:35
*** edcragg has joined #baserock13:37
*** gtristan has quit IRC13:42
*** edcragg has quit IRC13:56
*** edcragg has joined #baserock13:56
VLetrmxssam2, can you weigh in on ? since you wrote the initial schema i think? it seems DEFAULTs don't run the tests for Module::Build perl modules in version 7, where they did in version 6, which if unintended is a regression, the schema also apparently doesn't describe test-commands in chunk morphs. if version 7 is explicitly supposed to disable the tests for those modules then that's fine, though if that is the c14:09
ssam2sorry. no time today14:09
ssam2will look at it next week14:10
VLetrmxfair enough14:10
VLetrmxtiagogomes, if you're blocked i'm happy to +1 a version that doesn't touch cpan-mini-inject, the test stuff can be considered at a later date14:12
tiagogomesVLetrmx as I said, that still doesn't fix the problem of having no compliant definitions14:12
VLetrmxsorry i don't understand?14:13
pedroalvarezI though that moving defaults to definitions was to avoid some definition version changes14:17
tiagogomespedroalvarez huh? Moving DEFAULTS to definitions was to take out some hardcoded stuff from morph14:23
pedroalvarezthat too14:24
tiagogomespedroalvarez unfortunately morph reads the schema from the DEFAULTS itself from its source code, which makes it harder to adding new stuff to DEFAULTS without having to change morph14:25
pedroalvarezadding defaults before, needed a new version of definitions, so that you could first merge a patch in morph to add functionality and new version supported, and then change definitions14:25
VLetrmxmaybe the schema should live in definitions?14:26
pedroalvarezI think definitions version 7 is using the defaults from definitions. After that you are free to change those defaults I'd say14:26
tiagogomesVLetrmx the schema lives in definitions, but morph uses its copy :(14:27
VLetrmxahh yes sorry, i guess we can fix that easily enough?14:27
tiagogomesThe problem is that morph validates DEFAULTS against morphlib/schemas/defaults.json-schema, instead of definitions/schemas/defaults.json-schema14:28
tiagogomesVLetrmx yes, that should be easy to fix.14:29
VLetrmxcool :)14:29
tiagogomeswhat if for each definitions version that we release, we make a morph release for that version dropping the support for older versions.  So that a morph release can only build a single definitions version15:06
tiagogomese.g. the next release of morph would be called something like morph-v815:07
tiagogomesWe can then simply tell the users to use morph version X to build definitions version X15:07
tiagogomesThe case of building new Baserock systems using older systems can be handled by telling the user how to update morph in an existing baserock system15:09
tiagogomesAlthough that wouldn't work if morph needed some new package15:09
* tiagogomes should write an email15:14
persiaOne of the points of having separate versions for definitions and morph was to decouple the releases.15:14
persiaResynchonising them feels like a step backwards15:15
tiagogomestbh I that decoupling makes harder for the user to know which morph he needs to use to build some definitions version15:15
ssam2let's discuss this by email, indeed, i don't have time for a big irc discussion now but do have some thoughts15:32
ssam2tying Morph version to definitions version seems OK in principle, as long as we continue to have more than one build tool that reads definitions so we continue to test that the format isn't tangled up with Morph's internals15:34
ssam2also, the reason for having the DEFAULTS schema in Morph rather than in definitions is that, I don't want to make Morph only work on the Baserock reference system definitions15:35
ssam2you should be able to create a repo and add some .morph files and have Morph build them, without worrying about whether schemas/foo/bar exists in the same directory15:35
ssam2perhaps the copy in definitions.git should override the copy embedded in Morph.git .. but still, the schema should be describing what the build tools understand, and changing the schema isn't going to magically change the build tools to understand new things15:36
persia+1 for that rationale of not having schema in definitions15:38
* richard_maw made the point at the time that putting a schema in definitions would only let you narrow the set of acceptable definitions15:43
ssam2that's a good way to put it15:44
tiagogomesok, but then why cluster/system/stratum/chunk schemas are in definitions and not in morph?15:49
ssam2which, the .owl ones? they're not actually used by anything15:49
ssam2actually, the .jsonschema ones aren't used for anything either15:49
tiagogomesThe jsonschema15:49
ssam2definitions.git was just the simplest place to put them at the time15:50
ssam2they should probably live in a separate repo15:50
ssam2that build tools can embed as a submodule, or something15:50
richard_mawthis separate repo being the build tool's repo15:50
ssam2along with the definitiosn format15:50
ssam2(the text that currently lives in ikiwiki)15:50
persiarichard_maw: Rather a meta-definitions repo that definitions-compliant build-tools consume as a dependency15:51
* richard_maw considers that as an implementation detail15:52
persiaWell, yes, but as the original issue involved removing it from a specific build-tool repo, the semantic distinction makes clear the nature of the compromise.15:53
tiagogomesI don't want to involve another repo in the build process. Are we happy if the schemas are placed on morph repo and are documented in the wiki as well?15:57
tiagogomesMy ultimate goal is the use the schemas for the syntactic validation of the morphologies15:57
persiatiagogomes: No, because that means any build tool that wants to be definitions-complaint needs to build-depend on morph.15:58
persiaI also don't like wiki documentation: better would have a post-merge job that autogenerated docs to some URI.15:59
persia(as otherwise changes have to be done in two places simultaneously, which is annoying)15:59
ssam2the schemas can be placed in the morph repo, but I don't want that to be their "canonical home"16:00
ssam2i would much rather have a separate repo for stuff to do with the definitions format16:00
ssam2they could indeed live in the wiki for now, since it's a git repo16:01
tiagogomesssam2 how would the build tool then locate the schemas to do the validation?16:01
tiagogomespersia you're contracting yourself <persia> +1 for that rationale of not having schema in definitions16:02
tiagogomesI don't see how system/cluster/... need a different treatment thant the DEFAULTS schema16:02
ssam2tiagogomes: any way it wants to16:03
ssam2the point is that the schemas are a separate thing to the build tool16:03
ssam2if morph.git embeds a copy, that's fine16:03
ssam2if morph.git hardcodes the URL to fetch the schemas from, and downloads them, that's fine16:03
richard_mawFSVO fine16:04
tiagogomesewww, I don't think that is ok16:04
ssam2if morph.git includes the repo containing the schemas of the submodule, that's fine16:04
persiatiagogomes: I don't see the contradiction : I am in favour of the schema being out of definitons, but I assert that this doesn't necessarily mean it needs to be in morph.  There are many sorts of cheese.16:04
ssam2the point is that the schemas don't *live* in morph.git16:04
ZaraI wondered if 'there are many sorts of cheese' was a famous idiom, but just looked it up and nothing. Am wondering if persia is hungry.16:06
persiaI have a vague memory about a story in which there was an argument, maybe about cheddar vs. brie, and the final resolution was introducting something else: I think it was roquefort.  The story may not have been published, and my memory may be faulty.16:08
persiaMy assumption that this was a shared cultural meme was defintely faulty16:08
* SotK liked it, and thought it got the point across16:08
tiagogomespersia why build tool that wants to be definitions-complaint needs to build-depend on morph? The canonical place for schemas would be the wiki, morph would only have a copy for doing validation16:09
persiatiagogomes: I don't like the wiki as a canonical place for anything, because changes aren't peer-reviewed.16:10
persiaBut in the case where build-tools scraped a shared resource to determine what to do, rather than having the code in their own repository, I'd be less likely to call it a step back.16:10
*** nowster has quit IRC16:20
tiagogomesHaving another repo would also be useful to place the migration scripts16:25
ssam2the only challenge is what to call it :-)16:27
ssam2that's a good one16:30
*** nowster has joined #baserock16:35
*** CTtpollard has quit IRC16:46
persiaI like "schemas" as well.16:46
* rjek prefers schemata16:48
tiagogomeshow will the build tool consume the schemas? through a submodule?16:48
persiarjek: That's even better :)16:49
persiatiagogomes: My preference would be a build-dependency16:49
tiagogomespersia you mean adding the schemas as a chunk? The build tool needs the schemas before start building? or a package build dependency?16:52
persiaSo, right, dependency, not build-dependencu16:52
pedroalvarezhaha this is starting to be really confusing16:53
pedroalvarezI hope an email is sent to the list before doing anything :)16:53
persiaAlthough it may need to be a build-dependency for versions that cannot dynamically parse schemata16:53
* tiagogomes is failing to understand how the build tool will be able to use the schemata to validate the definitions that way16:55
persiaI don't know enough about the implementation.16:56
persiaMy current understanding is that there are schema in definitions.git and schema in morph.git16:56
ssam2schemas.git would install the schemas into /usr/share/baserock-schemas, morph would look for them there at runtime16:56
ssam2for example16:57
richard_mawor in its python package space, or wherever16:57
richard_mawlet morph embed it if it wants16:57
persiaIf schema are only consumed at runtime, then putting them in a chunk makes sense.  If they are needed at build time, then the build tool needs them as a build-depednency.16:57
persiaIf morph wants to consume them at runtime but embed them in the morph chunk, that is a build-depednency.16:57
tiagogomesssam2 that makes it more difficult to clone morph and use a version that uses newer definitions versions17:01
ssam2yeah, so submodule might be better17:01
* tiagogomes would prefer a copy in morph's source17:01
ssam2that's fine17:01
ssam2that's where we started, I think :-)17:01
persiaWhy is a copy in morph's source better than having it in the filesystem at morph build time?17:03
tiagogomes<tiagogomes>  that makes it more difficult to clone morph and use a version that uses newer definitions versions17:04
tiagogomesbecause if the schemata were in the filesystem outside morph's source, you would have to manually update it as well when updating morph17:07
persiaI consider that a feature.17:09
tiagogomesotherwise you could be attempting to build a new version of definitions, which doesn't have a version in the filesystem17:09
tiagogomeshow come more manual work for an user is a feature?17:09
persiaSure, but if the schema were in a chunk, rather than embedded, you could just update that, leaving morph alone.17:10
persiaUsers should never be running from git, so we're only talking about developer test use cases.17:10
richard_mawpersia: I can't think of cases where you'd want to update the schema without updating the build tool, since I think of it as an implementation detail of how the build tool knows that it understands what input it has been given17:11
richard_mawpersia: if you update the schema independently of the build tool then surely you can end up with a schema that validates, but the build tool chokes on17:11
persiarichard_maw: In my delusional vision, the build tool parses the schema to determine the appropriate behaviour17:11
* richard_maw doesn't think schemas can encode that level of detail, and understood that this was what the research into ontologies was for17:12
ssam2so Morph would be a meta-buildtool that parses 'schemas', then recodes itself on the fly to conform to them? that seems crazy17:12
persiaPerhaps, indeed.  I may be confused.17:12
tiagogomesssam2 that would be awesome :)17:13
* richard_maw doesn't think writing a meta-buildtool would be worth the effort17:13
richard_mawif we could make use of ontology data then maybe it would be possible17:13
richard_mawbut I don't know whether it would be easier to define the relationships between the data in ontologies or code17:14
*** gtristan has joined #baserock17:16
*** franred has quit IRC17:18
*** franred has joined #baserock17:39
* tiagogomes wonders from which age the use of 'alias' come from in the morphologies17:57
tiagogomeslooks like to be the old name for the morph and name keys17:58
*** bashrc_ has quit IRC17:59
richard_mawactually it was the idea that you might want to have multiple chunks with the same name and needed a different name to refer to them18:00
richard_mawidea being that the alias would match against the name in build-depends18:00
richard_mawmorph was the idea that the name of the morphology in the chunk repository would be different to the name of the chunk, it then became a file path18:00
*** tiagogomes has quit IRC18:02
*** edcragg has quit IRC18:05
*** jonathanmaw has quit IRC18:15
*** franred has quit IRC18:22
*** locallycompact has quit IRC18:34
*** ssam2 has quit IRC18:48
*** Lachlan1975 has quit IRC19:42

Generated by 2.15.3 by Marius Gedminas - find it at!