First Resource in scanpipe JSON results does not have a path

[JonoYang]

I set up scanpipe locally, run the scan_codebase pipeline on https://registry.npmjs.org/@uifabric/charting/-/charting-2.7.5.tgz, and downloaded the results in json when it was done. I tried to upload the scan directly to matchcode to see what happens and matchcode runs into an error because of the first Resource in the results:

{
  "for_packages": [],
  "path": "",
  "size": 0,
  "sha1": "",
  "md5": "",
  "copyrights": [],
  "holders": [],
  "authors": [],
  "licenses": [],
  "license_expressions": [],
  "emails": [],
  "urls": [],
  "status": "",
  "type": "directory",
  "extra_data": {},
  "name": "codebase",
  "extension": "",
  "programming_language": "",
  "mime_type": "",
  "file_type": ""
},

I'd expect there to be a path value for the codebase directory (which all the files sit in) and I would also expect that all the subsequent Resource paths to be prefixed by codebase as well. Conversely, since the rest of the paths are not prefixed with codebase, you could just opt to remove this Resource and I wouldn't think it would mess anything up in the results?

[tdruez]

I don't see any value keeping that empty entry, we should not create it in the first place.

@JonoYang what you be the benefits of prefixing everything with codebase/?

[pombredanne]

@tdruez re:

what you be the benefits of prefixing everything with codebase/?

this is a matter of model, not benefits at this stage: scancode (and every tool that can read scancode format) expects the paths in a scan to share a common root. We could relax this, but atm this is a hard requirement

[tdruez]

Displaying codebase/ every time we present a Resource in a UI (web, results, command line) take precious space without apparent purpose.
Paths can get pretty long already and I don't see the need in the ScanCode.io context to prefix everything with the same arbitrary string.
That been said, we should probably bring back the root prefix to keep compatibility with the toolkit for now.

[mjherzog]

As we go forward to merging Scans in SCIO it probably makes sense to support multiple top-level roots. Historically you had to combine directories under a common root for the Scan and I doubt that we want/need to support multiple target directories for one Scan, but we do want to be able to combine multiple Scans under one Project.

[tdruez]

@JonoYang the codebase/ root is not trimmed anymore. Could you try the latest code and confirm the fix?

[JonoYang]

@tdruez The changes made at 07e21fe fixes my issues. Thanks!