Enable debug option for pyschacl validation

[crisely09]

In the effort to solve #280 this option let's us use the debug version of the pyschacl validator.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 48.68421% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.40%. Comparing base (a1f7242) to head (3e3fe1a).
⚠️ Report is 76 commits behind head on master.

Files with missing lines	Patch %	Lines
kgforge/specializations/stores/bluebrain_nexus.py	18.18%	27 Missing ⚠️
kgforge/core/forge.py	33.33%	10 Missing ⚠️
...gforge/specializations/models/rdf/store_service.py	50.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #281      +/-   ##
==========================================
- Coverage   72.62%   72.40%   -0.23%     
==========================================
  Files          90       90              
  Lines        5761     5787      +26     
==========================================
+ Hits         4184     4190       +6     
- Misses       1577     1597      +20     

Flag	Coverage Δ
unittests	72.40% <48.68%> (-0.23%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MFSY]

I would do:
catch_exceptions= not debug

[crisely09]

I haven't implemented yet the option to delete distributions and deprecate files when registration fails. I would rather put that in a separate PR.

[joni-herttuainen]

Is it an absolute must to join these? Or, better yet, does the result dictionaries have to be converted to str?

[crisely09]

This is a choice, would you like to have the full schacl error result? Maybe we can give it back when the debug option is true. However, if the intention is to make a nicer Error log, we can add it here, I don't know, what do you think?

[joni-herttuainen]

No, no. Not the full shacl output, absolutely not. It's just for flexibility of further handling the output.
For example, if the dict you gather above is kept as a dict, it would allow to catch and handle the output on user side like:

try:  # this would happen in nexus-forge
    reason = "Flux Capacitor is broken"
    troubleshooting = {"attention": "Disconnect capacitor drive before opening", "safety": "Shield eyes from light", "actions": "do magic"}
    raise ValueError(reason, troubleshooting)
except ValueError as e:  # <-- error-handling on user side
    print(f"ERROR: {e.args[0]}")
    print("\nTroubleshooting Tips:")
    for k,v in e.args[1].items():
        print(f"\t{k.ljust(10)}: {v}")

OUTPUT:

ERROR: Flux Capacitor is broken

Troubleshooting Tips:
        attention : Disconnect capacitor drive before opening
        safety    : Shield eyes from light
        actions   : do magic

or we can just leave it as it is:

raise ValueError(reason, troubleshooting)

OUTPUT:

# <traceback>
ValueError: ('Flux Capacitor is broken', {'attention': 'Disconnect capacitor drive before opening', 'safety': 'Shield eyes from light', 'actions': 'do magic'})

[joni-herttuainen]

On nexus-forge side, you would still able to format the messages any way you want in execution.py. What do you think?

[crisely09]

Ah ok ok, I understand now your point, yes, I like it, I will make some changes, still not decided on if returning the dictionary, but already improved the message.

[joni-herttuainen]

I was testing the newest changes, and we're discussing about it in NSETM-2067.

Instead of opening a new ticket, I'll relay a comment from @jdcourcol, before this is pushed to master:

This is not great. "RegistrationError" does not bring any information when you are "Registering". The client knows that he is registering. It should be a "ValidationError" exception instead. And then having the information as text is unusable for programmatic access.

[ssssarah]

I have yet to run things to see what happens