-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
I will come back to this issue soon, perhaps we can discuss next week during our call. |
Maybe its rather ugly, and different audiences for OBO configs - maybe separate repo path is better. |
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:
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. |
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 |
(name and location of the file is arbitray, could be anything) |
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. |
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. |
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! |
This is great! I will start throwing things at the exemplar as soon as it is there. |
Sorry just catching up on this
Why move from top level
Top level is v standard - pom, package.json etc
…On Mon, Mar 2, 2020, 09:24 Nico Matentzoglu ***@***.***> wrote:
There is one other thing I did not think about. Based on a really old
comment by @cmungall <https://github.com/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
<https://github.com/PHI-base/phipo/blob/master/src/ontology/phipo-odk.yaml>.
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#328?email_source=notifications&email_token=AAAMMONWO7MAFEODCP64GWDRFPTTFA5CNFSM4K4IZZN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQFUXA#issuecomment-593517148>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOOPBGPU7IIZQ6DTLOTRFPTTFANCNFSM4K4IZZNQ>
.
|
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. |
@jamesaoverton Did you ever get around to produce an exemplar? Should we say file location is |
I haven't yet, sorry. Here's the draft config that inspired this thread: I have an irrational preference for three-letter file extensions (
|
Thanks! Yeah I was thinking analogies, and pom.xml came to mind.. so I thought project.yml may be fine. Maybe |
I think |
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:
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:
Second idea: Shove all this stuff into the OBO registry.
The text was updated successfully, but these errors were encountered: