Open broeder-j opened 10 months ago
If I understand the somesy code correctly.
I think this issue arises mainly because the original codemeta.json file is not used/parsed as an additional input to codemetapy, when the new codemeta.json is generated. So there is only a new codemeta file generated from the given sources and any additional information in the existing codemeta.json is ignored.
When somesy creates the new codemeta.json via codemetapy, one do not want conflicting information in the sources. Therefore, one needs to think about how to solve this, without conflicts. Maybe merge the original codemeta in afterwards to get all keys which somesy did not generate from the source. i.e could be a simple dict update of the original one with the new one (not optimal, but ok).
This merge will not solve the affiliation id issues, or any other nested things. Maybe one should do a rekursive @id merge. so a special treatment just for @ids
. or even a rekursive dict merge.
Also there should be a test with a rich codemeta, where 1. nothing changes, and 2. something changes, and in both cases only the given changes should happen, like a version update or any other update.
All somesy
does for codemeta is basically collecting relevant sources and input files, calling codemetapy
and saving the result if it changed. Somesy will not do anything more fancy than that.
What we could do is introduce an extra flag for a "supplemental" codemeta file to provide additional triples to be merged, which also would be passed to codemetapy
. It would be the responsibility of codemetapy
to overwrite or merge that extra information correctly.
We could also think about adding metadata fields to somesy that are passed to codemetapy using its interface (such as the base ID or certain specific codemeta fields not currently covered/inferred)
I removed the 'bug' tag, because overwriting codemeta.json
is expected and documented behavior.
I must say, I do not agree.
Every file is 'overwritten' by somesy, including pyproject.toml and CITATION.cff, but as a user I do not expect my specifications to be overwritten (like ignoring all other tool sections or metadata keys in pyproject.toml). i.e somesy's overwrite of codemeta.json in a completely different worse way, is unwanted and unexpected behavior by any user. The behavior of somesy is therefore inconsistent for the different files. And this is as I said above, in my view critical and until this is fixed I will not use somesy. So yes, it is current 'expecedt' behavior, but completely wrong. I would have put the label critical bug if existent.
Because CodeMeta is based on RDF / linked data, for technical reasons it is practically impossible to provide an equivalent behavior like we can for TOML, YAML and XML files (i.e. more or less conservative patching).
Concerning codemeta specifically, you could disable codemeta synchronization (--no-sync-codemeta
) if you dislike the behavior.
However, due to other idiosyncracies of your project setup (e.g. mixing setuptools and poetry in one pyproject.toml
), it looks like your use case and requirements are outside of the target group and scope of somesy
.
The main target audience for somesy is people who:
I would claim that:
Therefore, unfortunately, I think we have to "agree to disagree" here.
How about doing an rdf patch instead? i.e.
Run through what somesy does now, if no codemeta.json file exists.
Otherwise, if a codemeta.json exists generate the new triples, from the somesy.toml. Read in the existing codemeta.json, patch the graph then serialize it back, if the triples from the somesy.toml changed the graph. One would need to delete the triples that somesy can patch first from the graph. Would that not be a way? (whole Ids changes could be a problem, but one could apply them to some extent earlier.) Besides that it is technical hard. This type of issue is all over the place when dealing with linked data.
The current support is ONLY good if there is no codemeta.json in the first place. People who currently use somesy care about metadata, so there is likely a codemeta.json, because they like start from here: https://codemeta.github.io/codemeta-generator/
It is good that there is already a feature to disable the codemeta-sync. That makes it useable for me in the other context. Thanks!
An other solution could be:
Where all the additional information is also in the somesy,toml, i.e where somesy.toml can be as rich as codemeta.json. Then one could go with the full recreation like no and not change any logic expect piping the information through to codemetapy. i.e allow to provide any key codemeta also allows in the richness that codemeta.json allows.
Describe the bug
somesy sync
deletes existing ids from affiliations of authors and contributors. it also removes: the '@id' from the resource itself, all keys-value pairs that codemeta allows, but codemeta somesy internal does not.For me this is a critical bug, because of which I won't use somesy until this is not the case anymore.
Expected behavior
To Reproduce Steps to reproduce the behavior:
(sorry for not condensing to a minimal example). Some of the changes come because of python project metadata. Example codemeta.json in:
somesy.toml in
'crippled' codemeta.json out.