I went through all the tests in test_storage.py. It appears that only content_fossology_license_get needs to be refactored. All other storage methods return a dictionary or a list of dictionaries, where each dictionary has multiple keys.

I am familiar with the web APIs and I went through the discussion in T782. When you say output a single dictionary, I believe you mean something like this

{
  sha1: [
    {tool: TOOL, licenses: [licences]},
    {tool: TOOL, licenses: [licences]}
  ],

I followed swh-docker-dev documentation to host the setup locally. But it only hosts the web portal, I couldn't access locally hosted documentation. How can I see the effect my changes are making?

I followed swh-docker-dev documentation to host the setup locally. But it only hosts the web portal, I couldn't access locally hosted documentation. How can I see the effect my changes are making?

From my point of view, it is not a big deal if some docstrings and url declarations exceed the 80 columns limit.

what is the expected formatting for snippets like these

the 80 character mark is -----------------------------------------------------------------|
@browse_route(r'origin/(?P<origin_type>[a-z]+)/url/(?P<origin_url>.+)/visit/(?P<timestamp>.+)/directory/', # noqa
              r'origin/(?P<origin_type>[a-z]+)/url/(?P<origin_url>.+)/visit/(?P<timestamp>.+)/directory/(?P<path>.+)/', # noqa
              r'origin/(?P<origin_type>[a-z]+)/url/(?P<origin_url>.+)/directory/', # noqa
              r'origin/(?P<origin_type>[a-z]+)/url/(?P<origin_url>.+)/directory/(?P<path>.+)/', # noqa
              r'origin/(?P<origin_url>.+)/visit/(?P<timestamp>.+)/directory/', # noqa
              r'origin/(?P<origin_url>.+)/visit/(?P<timestamp>.+)/directory/(?P<path>.+)/', # noqa
              r'origin/(?P<origin_url>.+)/directory/', # noqa
              r'origin/(?P<origin_url>.+)/directory/(?P<path>.+)/', # noqa
              view_name='browse-origin-directory')
def origin_directory_browse(request, origin_url, origin_type=None,
                            timestamp=None, path=None):
    """Django view for browsing the content of a directory associated
    to an origin for a given visit.

This task is completed it can be closed.

Though I admit I'm not familiar with any reformatting tool, so it's possible they support it.

This should probably be reformatted manually, because our docstrings use special formats (used by sphinx and sphinxcontrib-httpdomain when building the documentation), which these tools are not aware of and may break.

I have checked autopep8 and black, none of these claim to reformat long doc strings properly. This may require custom scripting or editing it by hand. However autopep8 did suggest some other changes when I tried it out. Is there a reason a linter is used instead of a formatter?

Don't use the origin_metadata of swh-storage, it contains a different kind of metadata that we are not interested in for now.

I wan to clarify the return value for this api. In swh-storage, table origin_metadata contains the metadata of an origin for a visit, listing etc. The primary key is an auto incremented value. This means that there can be multiple entries for a single origin_id. What is the expected JSON response for this API? I can include origin_id and a list of metadata values, is there anything else to return?

Ok I'll try to implement and test this by tomorrow.

In T1613#33881, @twitu wrote:

If this issue is open, I can work on this. I believe I have to add the endpoint in /swh-web/swh/web/api/views/origin.py.

This is will also require adding a function to in swh/web/common/service.py that makes the query to swh-storage. The response will then have to be converted to a json response. I would like to take this up and add this api. Please suggest if there is wrong with the changes I am suggesting.

D1582 has been pushed the task can be closed

If this issue is open, I can work on this. I believe I have to add the endpoint in /swh-web/swh/web/api/views/origin.py. I will probably have to populate the db with an origin and test the api by making http requests, or is there a better way?

Okay, @nahimilega Thanks. Will submit the correct patch soon

We need three backquotes after the line

@nahimilega I think I can work on this. Do you want the whole text after lister gnu into its own distinct block ( using triple backquote)

All columns commented in swh-scheduler, waiting review.
Some columns for swh-storage required a small discussion to frame appropriate comments.

All columns are already commented in swh-indexer

Have added a few comments in D1582

The latest upgrade is 136.sql while the version in 30-swh-schema.sql is 133. Should I name the next upgrade 137?

there seems to be an inconsistency between sql/upgrades and latest sql version in swh-storage. The latest upgrade is 136.sql while the version in 30-swh-schema.sql is 133. Should I name the next upgrade 137?

Antoine, outright marvellous! The notebooks render beautifully. And already now in production!
Because of this, I consider SHA as the premier choice of citing GitHub repos.
Many thanks!

@dirkroorda , this is now deployed to production. See [1] as an example.

Sure go ahead ;)

Hey @faux, I am still working on this.