Question: how to contribute new functionality and updates?

[dgarijo]

Hello, I open this issue here after a discussion with @moranegg.
In my group, we have forked the codemeta-generator project adding a functionality to auto-populate many fields in the client.

We are also extending it to represent reference publication authors, include keywords that are defined terms, and other features that we consider important to ease using it.

When I talked to @moranegg she suggested opening a PR, but we are adding a small fastapi server application for completing the repo metadata using one of our tools, and I am not sure that would be welcome here. Alternatively, I am happy to do a PR to a new branch of the repo, but we don't have permission for doing it.

I open this issue for discussing this collaboratively. If you want, we can also consider adding a new repo, but it may be too much.

Fork information:

• GitHub: https://github.com/oeg-upm/auto-codemeta-generator/tree/master
• URL: https://autocodemeta.linkeddata.es/

[progval]

Could the auto-codemeta-generator be a separate tool? People would use it to get an initial codemeta.json, that they import in the codemeta-generator.

We could also add support in the codemeta-generator to import a codemeta.json from a query parameter or fragment; so that the auto-codemeta-generator could link directly to the codemeta-generator so users don't even need to copy&paste.

but we are adding a small fastapi server application for completing the repo metadata using one of our tools, and I am not sure that would be welcome here.

That's indeed why I'm hesitant to merge it. Two other options to rewrite the server code to run in the browser (but that's a lot of work) or to use something like pyodide to run your existing Python code (but that would bloat the page size).

Alternatively, I am happy to do a PR to a new branch of the repo, but we don't have permission for doing it.

What would you do with that new branch?

[dgarijo]

Could the auto-codemeta-generator be a separate tool? People would use it to get an initial codemeta.json, that they import in the codemeta-generator.
We could also add support in the codemeta-generator to import a codemeta.json from a query parameter or fragment; so that the auto-codemeta-generator could link directly to the codemeta-generator so users don't even need to copy&paste.

It could be a separate tool, but it is built on top of the codemeta-generator (i.e. the ui is essentially the same). Why would a user import a codemeta.json file from one to the other if autocodemeta already validates it? We already had services to generate a codemeta file, but having people to copy paste it or import it in here seems like a hassle. That is why we extended the functionality of the ui.

That's indeed why I'm hesitant to merge it. Two other options to rewrite the server code to run in the browser (but that's a lot of work) or to use something like pyodide to run your existing Python code (but that would bloat the page size).

I am not sure about the work needed for either approach. Wouldn't it also include drastic changes for the maintenance of the tool?

What would you do with that new branch?
You could have 2 versions of the tool: one that runs the server (with the box to include your code repo) and another one that doesn't. I guess this will make it easier to share client updates between the two projects.

We can also separate the server in a different repo, and add a configuration parameter so that the client launches with the box to include the repository or not, depending on that config file. If a server is configured, then it would call to the service API. If not, the default client is launched. I think this solution is elegant

[progval]

Wouldn't it also include drastic changes for the maintenance of the tool?

I think it would because that's considerably more code that would need its own test suite, plus testing the integration between the two.

On second thought, I think pyodide could be a good idea. The interpreter itself weighs 3MB, and the stdlib 2.5MB. We can probably cut down the stdlib to just the modules sssom needs, so that gives a decently small bundle.

And then we could by default not display the import widget, but add it dynamically to browsers that support wasm after they successfully downloaded the wasm bundle.

This way, no need to maintain a server. What do you think?

[dgarijo]

@progval thanks for the suggestion. The somef package is around 6 mb and has a few dependencies, so we'll have to experiment a bit to see how feasible this is. It also needs to configure a token if you use GitHub repos, but I guess we can send it through a configuration file. The benefit of not maintaining a server is very tempting, so we'll explore this option.

Since we are still working on refining the autocodemeta generator, let me see first that it reaches a level we are happy with, including tests for the new fields we want to support (e.g., authors of the reference publication, allowing keywords to be external terms, adding versions to software dependencies, etc.), and then we'll look into pyodide. I opened oeg-upm#18 to keep track of this.

[progval]

It also needs to configure a token if you use GitHub repos

Github's API supports anonymous requests, just with a lower rate-limit. It should be fine as this is meant to be used by end users.