Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coordination on project YAML schema #328

Open
jamesaoverton opened this issue Feb 26, 2020 · 16 comments
Open

Coordination on project YAML schema #328

jamesaoverton opened this issue Feb 26, 2020 · 16 comments

Comments

@jamesaoverton
Copy link
Contributor

Can we converge on a common project.yml file schema?

Background: As discussed in #298, I'm very keen to follow ODK's lead on lots of things, even though I usually want only a subset of ODK features for my ontology projects.

Immediate use case: My team is working on a script for reserving term IDs, which needs to know GitHub repo coordinates, IDSPACE, and ID pattern stuff. ontodev/gizmos#2

ODK uses YAML config files, many of which are here in configs/. They already contain most of what that script needs (IDSPACE, GitHub coordinates), plus other useful stuff (dependencies, products, etc.)

Across OBO we have a few other project YAML files:

  • OBO registry YAML files, with lots of project metadata, now including some build and dependency information
  • PURL config files, which have the IDSPACE but are specialized

We also use or could use project configuration data for DROID, ROBOT, and Protege. And in working on the OBO Dashboard I realized that if I knew that a project was using the GitHub release mechanism, then the dashboard code could look there for new releases. I can think of many more use cases, and there may be relevant open issues already.

I'm not asking for one config file to rule them all. I think the separation between OBO registry and PURL config files is ultimately more helpful than it is annoying. On the other hand, the line between ODK config and OBO registry is not clear to me.

I don't know the right way to go with this. Maybe it won't work at all. But I'll pitch two ideas. First idea:

  1. Draw a sharper line between OBO registry and ODK configs
    • e.g. maybe move GitHub coordinates to OBO registry
    • ODK repositories would still keep local copies of both files
  2. Update code to read both OBO registry and ODK configs and work with the merged results
  3. Expand the scope of ODK configs to include stuff other tools need, e.g. ID patterns, term reservation branch name
  4. Define a schema for ODK configs

Second idea: Shove all this stuff into the OBO registry.

@matentzn
Copy link
Contributor

I will come back to this issue soon, perhaps we can discuss next week during our call.

@matentzn
Copy link
Contributor

matentzn commented Mar 2, 2020

Maybe its rather ugly, and different audiences for OBO configs - maybe separate repo path is better.

@jamesaoverton
Copy link
Contributor Author

jamesaoverton commented Mar 2, 2020

On the call there was consensus that merging this tool config into the main OBO project metadata files is a bad idea.

Nico volunteered to move the ODK configs to a new home that we have shared access to. I like that idea, but it's really important that we don't break these ODK configs and Nico's workflows!

We discussed two possible new homes:

  1. new directory in OBOFoundry.github.io repo
  2. new repo under OBOFoundry org

I think (2) is a better option, mainly so we can restrict write access to a handful of developers.

We should also write a strict schema, and add Travis check to enforce the schema.

We'd really like to hear @cmungall's thoughts.

@matentzn
Copy link
Contributor

matentzn commented Mar 2, 2020

There is one other thing I did not think about. Based on a really old comment by @cmungall, I recently started to migrate the configs to a standard location in the ontology repository itself, namely src/ontology/$(ONT)-odk.yaml, e.g. src/ontology/wbphenotype-odk.yaml, for an example see here. That would also be an option which is less centralised and gives the editors more fine-grained control. Again, pros and cons. I just wanted to register that as option 3.

@matentzn
Copy link
Contributor

matentzn commented Mar 2, 2020

(name and location of the file is arbitray, could be anything)

@jamesaoverton
Copy link
Contributor Author

I'm also fine if these files are in a predictable place in each project's repo. I mainly care about a shared schema that we agree to coordinate on.

On today's call we didn't talk about coordinating with Protege, but way back at ICBO 2017 in Newcastle there were positive feelings about that possibility.

@matentzn
Copy link
Contributor

matentzn commented Mar 2, 2020

I agree; shall we manage a full-blown exemplar together for now (so we can continue working), and just shove stuff in there whenever we need things? We can simply add one yaml file in a location we both have access to (obofoundry github), and add example entries to it whenever we need a new feature. We can develop a schema in parallel (in the same directory), but I think exemplar (plus some comments) is, for now, easier until I am out of these mad times.

@jamesaoverton
Copy link
Contributor Author

Yes, that sounds good. I'll take care of those first steps. When we have an exemplar I'll link to it from this issue and close. Thanks!

@jamesaoverton
Copy link
Contributor Author

@cmungall @matentzn I talked to Rafael today about possibly coordinating this with Protege and he started the new issue above.

@matentzn
Copy link
Contributor

This is great! I will start throwing things at the exemplar as soon as it is there.

@cmungall
Copy link
Contributor

cmungall commented Mar 12, 2020 via email

@matentzn
Copy link
Contributor

matentzn commented Mar 12, 2020

Current location does not matter. I just moved it there at some point for no particular reason, but happy to use top level as well.

@matentzn
Copy link
Contributor

@jamesaoverton Did you ever get around to produce an exemplar? Should we say file location is project.yaml in top level of repo?

@jamesaoverton
Copy link
Contributor Author

I haven't yet, sorry. Here's the draft config that inspired this thread:

https://github.com/ontodev/gizmos/blob/create_term_id_reservation_script/scripts/gizmos.yml

I have an irrational preference for three-letter file extensions (.yml) that you can ignore.

project.yml seems very generic, and I'm worried it will conflict with other tools, but I don't have a better suggestion at the moment.

@matentzn
Copy link
Contributor

Thanks! Yeah I was thinking analogies, and pom.xml came to mind.. so I thought project.yml may be fine. Maybe ontology-config.yml better?

@jamesaoverton
Copy link
Contributor Author

I think ontology-config.yml is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants