You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, we identified writing the scripts that pull data from previously unknown APIs (Provider API Scripts) as the best entry points for new community contributors.
The Provider API Scripts are required to provide either a license url or a pair of license name and license version. If those were not valid, the ImageStore repository class would silently just not write the data for the image. We did not validate the licenses in the Provider API scripts because we felt that it would add complexity of learning about inner details of license naming for the new contributors.
During the discussion of moving license validation from the ImageStore repository to the individual provider API scripts, we probably found a way to both validate the licenses and clearly show if validation failed, as well as not to bog the new contributors down with details about licenses (there are more than 500 versions!)
Solution Description
We can create a cookiecutter-like template for creating a Provider API script:
Add a folder with a Provider API Script Template, a Provider API Script Test template, and a Provider API Workflow Template
Write a CLI script that fills in the templates with Provider name, and save the files in the appropriate locations.
To make sure that license validation is simplified for the new contributors, we can:
provide clearer documentation about what we can accept as a valid license
import the function that validates license_name and license_version pair into the Provider API Script template so that the user could use it during script writing and testing.
have a clearer indication if the license_url or license_name and license_version pair are invalid so that the user can fix them if possible. Currently, if the license data is not valid, the scripts do not provide very clear feedback, failing quietly.
Alternatives
Move license validation to the Provider API scripts, and add more documentation about it.
This would probably make the extraction and saving of license information easier. However, with a template, we can also get better-quality scripts by providing best practices and good examples within it.
Additional context
This template will also help when we are adding Audio sources in the short term, and other Open licenses in the long term.
The text was updated successfully, but these errors were encountered:
Problem Description
Previously, we identified writing the scripts that pull data from previously unknown APIs (Provider API Scripts) as the best entry points for new community contributors.
The Provider API Scripts are required to provide either a license url or a pair of license name and license version. If those were not valid, the ImageStore repository class would silently just not write the data for the image. We did not validate the licenses in the Provider API scripts because we felt that it would add complexity of learning about inner details of license naming for the new contributors.
During the discussion of moving license validation from the ImageStore repository to the individual provider API scripts, we probably found a way to both validate the licenses and clearly show if validation failed, as well as not to bog the new contributors down with details about licenses (there are more than 500 versions!)
Solution Description
We can create a cookiecutter-like template for creating a Provider API script:
Add a folder with a Provider API Script Template, a Provider API Script Test template, and a Provider API Workflow Template
Write a CLI script that fills in the templates with Provider name, and save the files in the appropriate locations.
To make sure that license validation is simplified for the new contributors, we can:
Alternatives
This would probably make the extraction and saving of license information easier. However, with a template, we can also get better-quality scripts by providing best practices and good examples within it.
Additional context
This template will also help when we are adding Audio sources in the short term, and other Open licenses in the long term.
The text was updated successfully, but these errors were encountered: