| *** richard_maw has quit IRC | 04:48 | |
| *** richard_maw has joined #baserock | 04:48 | |
| *** ChanServ sets mode: +v richard_maw | 04:48 | |
| *** tristan has joined #baserock | 06:04 | |
| *** tristan is now known as Guest6157 | 06:05 | |
| *** Guest6157 is now known as gtristan | 06:06 | |
| *** gtristan has quit IRC | 06:13 | |
| *** gtristan has joined #baserock | 06:14 | |
| *** gtristan has quit IRC | 06:22 | |
| *** gtristan has joined #baserock | 06:28 | |
| *** gtristan has quit IRC | 07:17 | |
| *** gtristan has joined #baserock | 07:18 | |
| *** gtristan has quit IRC | 07:41 | |
| *** gtristan has joined #baserock | 07:41 | |
| *** CTtpollard has quit IRC | 08:35 | |
| *** CTtpollard has joined #baserock | 08:41 | |
| *** locallycompact has joined #baserock | 08:41 | |
| *** bashrc_ has joined #baserock | 09:07 | |
| *** edcragg has joined #baserock | 09:15 | |
| *** tiagogomes has joined #baserock | 09:29 | |
| *** franred has joined #baserock | 09:41 | |
| *** jonathanmaw has joined #baserock | 10:02 | |
| *** ssam2 has joined #baserock | 10:04 | |
| *** ChanServ sets mode: +v ssam2 | 10:04 | |
| *** rdale has joined #baserock | 10:08 | |
| *** rdale_ct_ has quit IRC | 10:10 | |
| *** CTtpollard has quit IRC | 10:11 | |
| *** ssam2 has quit IRC | 10:13 | |
| *** bjdooks has quit IRC | 10:13 | |
| *** bjdooks has joined #baserock | 10:19 | |
| *** Lachlan1975 has joined #baserock | 10:22 | |
| *** ssam2 has joined #baserock | 10:25 | |
| *** ChanServ sets mode: +v ssam2 | 10:25 | |
| *** CTtpollard has joined #baserock | 10:26 | |
| *** gtristan has quit IRC | 10:41 | |
| *** gtristan has joined #baserock | 11:14 | |
| *** nowster has quit IRC | 13:05 | |
| *** franred has quit IRC | 13:06 | |
| *** franred has joined #baserock | 13:19 | |
| *** nowster has joined #baserock | 13:20 | |
| *** edcragg has quit IRC | 13:35 | |
| *** edcragg has joined #baserock | 13:37 | |
| *** gtristan has quit IRC | 13:42 | |
| *** edcragg has quit IRC | 13:56 | |
| *** edcragg has joined #baserock | 13:56 | |
| VLetrmx | ssam2, can you weigh in on https://gerrit.baserock.org/#/c/1527/2 ? 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 c | 14:09 |
|---|---|---|
| ssam2 | sorry. no time today | 14:09 |
| ssam2 | will look at it next week | 14:10 |
| VLetrmx | fair enough | 14:10 |
| VLetrmx | tiagogomes, 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 date | 14:12 |
| tiagogomes | VLetrmx as I said, that still doesn't fix the problem of having no compliant definitions | 14:12 |
| VLetrmx | sorry i don't understand? | 14:13 |
| pedroalvarez | I though that moving defaults to definitions was to avoid some definition version changes | 14:17 |
| tiagogomes | pedroalvarez huh? Moving DEFAULTS to definitions was to take out some hardcoded stuff from morph | 14:23 |
| pedroalvarez | that too | 14:24 |
| tiagogomes | pedroalvarez 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 morph | 14:25 |
| pedroalvarez | adding 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 definitions | 14:25 |
| VLetrmx | maybe the schema should live in definitions? | 14:26 |
| pedroalvarez | I think definitions version 7 is using the defaults from definitions. After that you are free to change those defaults I'd say | 14:26 |
| tiagogomes | VLetrmx the schema lives in definitions, but morph uses its copy :( | 14:27 |
| VLetrmx | ahh yes sorry, i guess we can fix that easily enough? | 14:27 |
| tiagogomes | The problem is that morph validates DEFAULTS against morphlib/schemas/defaults.json-schema, instead of definitions/schemas/defaults.json-schema | 14:28 |
| tiagogomes | VLetrmx yes, that should be easy to fix. | 14:29 |
| VLetrmx | cool :) | 14:29 |
| tiagogomes | what 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 version | 15:06 |
| tiagogomes | e.g. the next release of morph would be called something like morph-v8 | 15:07 |
| tiagogomes | We can then simply tell the users to use morph version X to build definitions version X | 15:07 |
| tiagogomes | The case of building new Baserock systems using older systems can be handled by telling the user how to update morph in an existing baserock system | 15:09 |
| tiagogomes | Although that wouldn't work if morph needed some new package | 15:09 |
| * tiagogomes should write an email | 15:14 | |
| persia | One of the points of having separate versions for definitions and morph was to decouple the releases. | 15:14 |
| persia | Resynchonising them feels like a step backwards | 15:15 |
| tiagogomes | tbh I that decoupling makes harder for the user to know which morph he needs to use to build some definitions version | 15:15 |
| ssam2 | let's discuss this by email, indeed, i don't have time for a big irc discussion now but do have some thoughts | 15:32 |
| ssam2 | tying 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 internals | 15:34 |
| ssam2 | also, 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 definitions | 15:35 |
| ssam2 | you 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 directory | 15:35 |
| ssam2 | perhaps 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 things | 15:36 |
| persia | +1 for that rationale of not having schema in definitions | 15:38 |
| * richard_maw made the point at the time that putting a schema in definitions would only let you narrow the set of acceptable definitions | 15:43 | |
| ssam2 | that's a good way to put it | 15:44 |
| tiagogomes | ok, but then why cluster/system/stratum/chunk schemas are in definitions and not in morph? | 15:49 |
| ssam2 | which, the .owl ones? they're not actually used by anything | 15:49 |
| ssam2 | actually, the .jsonschema ones aren't used for anything either | 15:49 |
| tiagogomes | The jsonschema | 15:49 |
| ssam2 | definitions.git was just the simplest place to put them at the time | 15:50 |
| ssam2 | they should probably live in a separate repo | 15:50 |
| ssam2 | that build tools can embed as a submodule, or something | 15:50 |
| richard_maw | this separate repo being the build tool's repo | 15:50 |
| ssam2 | along with the definitiosn format | 15:50 |
| ssam2 | (the text that currently lives in ikiwiki) | 15:50 |
| persia | richard_maw: Rather a meta-definitions repo that definitions-compliant build-tools consume as a dependency | 15:51 |
| * richard_maw considers that as an implementation detail | 15:52 | |
| persia | Well, 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 |
| tiagogomes | I 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 |
| tiagogomes | My ultimate goal is the use the schemas for the syntactic validation of the morphologies | 15:57 |
| persia | tiagogomes: No, because that means any build tool that wants to be definitions-complaint needs to build-depend on morph. | 15:58 |
| persia | I 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 |
| ssam2 | the schemas can be placed in the morph repo, but I don't want that to be their "canonical home" | 16:00 |
| ssam2 | i would much rather have a separate repo for stuff to do with the definitions format | 16:00 |
| ssam2 | they could indeed live in the wiki for now, since it's a git repo | 16:01 |
| tiagogomes | ssam2 how would the build tool then locate the schemas to do the validation? | 16:01 |
| tiagogomes | persia you're contracting yourself <persia> +1 for that rationale of not having schema in definitions | 16:02 |
| tiagogomes | I don't see how system/cluster/... need a different treatment thant the DEFAULTS schema | 16:02 |
| tiagogomes | s/thant/than | 16:02 |
| ssam2 | tiagogomes: any way it wants to | 16:03 |
| ssam2 | the point is that the schemas are a separate thing to the build tool | 16:03 |
| ssam2 | if morph.git embeds a copy, that's fine | 16:03 |
| ssam2 | if morph.git hardcodes the URL to fetch the schemas from, and downloads them, that's fine | 16:03 |
| richard_maw | FSVO fine | 16:04 |
| ssam2 | yeah | 16:04 |
| tiagogomes | ewww, I don't think that is ok | 16:04 |
| ssam2 | if morph.git includes the repo containing the schemas of the submodule, that's fine | 16:04 |
| persia | tiagogomes: 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 |
| ssam2 | the point is that the schemas don't *live* in morph.git | 16:04 |
| Zara | I 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 |
| persia | I 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 |
| persia | My assumption that this was a shared cultural meme was defintely faulty | 16:08 |
| * SotK liked it, and thought it got the point across | 16:08 | |
| tiagogomes | persia 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 validation | 16:09 |
| persia | tiagogomes: I don't like the wiki as a canonical place for anything, because changes aren't peer-reviewed. | 16:10 |
| persia | But 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 IRC | 16:20 | |
| tiagogomes | Having another repo would also be useful to place the migration scripts | 16:25 |
| ssam2 | true! | 16:26 |
| ssam2 | the only challenge is what to call it :-) | 16:27 |
| tiagogomes | schemas? | 16:29 |
| ssam2 | that's a good one | 16:30 |
| *** nowster has joined #baserock | 16:35 | |
| *** CTtpollard has quit IRC | 16:46 | |
| persia | I like "schemas" as well. | 16:46 |
| * rjek prefers schemata | 16:48 | |
| tiagogomes | how will the build tool consume the schemas? through a submodule? | 16:48 |
| persia | rjek: That's even better :) | 16:49 |
| persia | tiagogomes: My preference would be a build-dependency | 16:49 |
| tiagogomes | persia you mean adding the schemas as a chunk? The build tool needs the schemas before start building? or a package build dependency? | 16:52 |
| persia | chunk | 16:52 |
| persia | So, right, dependency, not build-dependencu | 16:52 |
| pedroalvarez | haha this is starting to be really confusing | 16:53 |
| pedroalvarez | I hope an email is sent to the list before doing anything :) | 16:53 |
| persia | Although it may need to be a build-dependency for versions that cannot dynamically parse schemata | 16:53 |
| * tiagogomes is failing to understand how the build tool will be able to use the schemata to validate the definitions that way | 16:55 | |
| persia | I don't know enough about the implementation. | 16:56 |
| persia | My current understanding is that there are schema in definitions.git and schema in morph.git | 16:56 |
| ssam2 | schemas.git would install the schemas into /usr/share/baserock-schemas, morph would look for them there at runtime | 16:56 |
| ssam2 | for example | 16:57 |
| richard_maw | or in its python package space, or wherever | 16:57 |
| richard_maw | let morph embed it if it wants | 16:57 |
| persia | If 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 |
| persia | If morph wants to consume them at runtime but embed them in the morph chunk, that is a build-depednency. | 16:57 |
| tiagogomes | ssam2 that makes it more difficult to clone morph and use a version that uses newer definitions versions | 17:01 |
| ssam2 | yeah, so submodule might be better | 17:01 |
| * tiagogomes would prefer a copy in morph's source | 17:01 | |
| ssam2 | that's fine | 17:01 |
| ssam2 | that's where we started, I think :-) | 17:01 |
| persia | Why 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 versions | 17:04 |
| persia | Why? | 17:05 |
| tiagogomes | because if the schemata were in the filesystem outside morph's source, you would have to manually update it as well when updating morph | 17:07 |
| persia | I consider that a feature. | 17:09 |
| tiagogomes | otherwise you could be attempting to build a new version of definitions, which doesn't have a version in the filesystem | 17:09 |
| tiagogomes | how come more manual work for an user is a feature? | 17:09 |
| persia | Sure, but if the schema were in a chunk, rather than embedded, you could just update that, leaving morph alone. | 17:10 |
| persia | Users should never be running from git, so we're only talking about developer test use cases. | 17:10 |
| richard_maw | persia: 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 given | 17:11 |
| richard_maw | persia: 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 on | 17:11 |
| persia | richard_maw: In my delusional vision, the build tool parses the schema to determine the appropriate behaviour | 17:11 |
| * richard_maw doesn't think schemas can encode that level of detail, and understood that this was what the research into ontologies was for | 17:12 | |
| ssam2 | so Morph would be a meta-buildtool that parses 'schemas', then recodes itself on the fly to conform to them? that seems crazy | 17:12 |
| persia | Perhaps, indeed. I may be confused. | 17:12 |
| tiagogomes | ssam2 that would be awesome :) | 17:13 |
| * richard_maw doesn't think writing a meta-buildtool would be worth the effort | 17:13 | |
| richard_maw | if we could make use of ontology data then maybe it would be possible | 17:13 |
| richard_maw | but I don't know whether it would be easier to define the relationships between the data in ontologies or code | 17:14 |
| *** gtristan has joined #baserock | 17:16 | |
| *** franred has quit IRC | 17:18 | |
| *** franred has joined #baserock | 17:39 | |
| * tiagogomes wonders from which age the use of 'alias' come from in the morphologies | 17:57 | |
| tiagogomes | looks like to be the old name for the morph and name keys | 17:58 |
| *** bashrc_ has quit IRC | 17:59 | |
| richard_maw | actually it was the idea that you might want to have multiple chunks with the same name and needed a different name to refer to them | 18:00 |
| richard_maw | idea being that the alias would match against the name in build-depends | 18:00 |
| richard_maw | morph 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 path | 18:00 |
| *** tiagogomes has quit IRC | 18:02 | |
| *** edcragg has quit IRC | 18:05 | |
| *** jonathanmaw has quit IRC | 18:15 | |
| *** franred has quit IRC | 18:22 | |
| *** locallycompact has quit IRC | 18:34 | |
| *** ssam2 has quit IRC | 18:48 | |
| *** Lachlan1975 has quit IRC | 19:42 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!