Better handling of pydantic error msgs

[pierrotsmnrd]

Fixes #535 (work in progress)

Description

The purpose of this PR is to present more user-friendly error messages, in case of invalid YAML specification when trying to create an env.

Pull request checklist

• Did you test this change locally?
• Did you update the documentaion (if required)?
• Did you add/update relevant tests for this change (if required)?

Additional information

I consider this PR as a work in progress.

• the unique error case currently handled, might have its human-friendly message improved
• we might handle there other cases than the one described in the original issues
• Does the "translation" pydantic error ➞ human need to be done somewhere else ?
• Also : unit tests

[costrouc]

Personally there are two things that have bugged me about pydantic error messages:

• context
• human readable messages

For context it would be nice to see the offending lines/location

For human readable messages I imagine it might be worth putting some work into the schema CondaSpecification and adding some additional validation to ensure that the messages are generally better.

[asmeurer]

A more scalable way to handle this would be to have a subclass of the HTTPException class that handles the translation in the constructor.

[netlify]

✅ Deploy Preview for kaleidoscopic-dango-0cf31d canceled.

Name	Link
🔨 Latest commit	5f078e1
🔍 Latest deploy log	https://app.netlify.com/sites/kaleidoscopic-dango-0cf31d/deploys/65111649caeaed0008753136

[pierrotsmnrd]

I have followed @costrouc 's recommendations.

Now, the validation is done in the CondaSpecification class, and all the validation errors are raised (we use to display only one)

For instance, for a spec where the name of the env is missing, and an empty dependency exists, we have the two errors like this :

We need to add a fix in the UI to handle the \n in between the two errors.

[asmeurer]

You should use a custom exception here. Something else could raise a ValueError which wouldn't have a list in its args, and that probably shouldn't be converted to an HTTPException anyway.

[pierrotsmnrd]

Done.

[trallard]

This looks good to me, @asmeurer since you had reviewed this before, can you have another look at this and approve if applicable?

[asmeurer]

This looks fine. We'll probably want to refactor this if we start translating a lot more error messages, but with just a couple the way it's written now is fine.