Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #1138 - vscode-python - Make 'author' parsing less strict #1141

Merged
merged 1 commit into from
Jan 1, 2020
Merged

Fix #1138 - vscode-python - Make 'author' parsing less strict #1141

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 21 additions & 1 deletion src/Extensions/ExtensionManifest.re
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,26 @@ module ExtensionKind = {
| [@name "workspace"] Workspace;
};

module Author = {
[@deriving show]
type t = option(string);

let of_yojson_exn =
fun
| `String(v) => Some(v)
| v =>
Yojson.Safe.(
{
Util.member("name", v) |> Util.to_string_option;
}
);

let of_yojson = json =>
tryToResult(~msg="Error parsing author", () => of_yojson_exn(json));

let to_yojson = _author => `Null;
};
Comment on lines +18 to +36
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, that's a lot of ceremony for what's basically just a single function in a combinator-based API.

I wonder if we should consider using ocaml-decoders instead. There are of course other benefits too, like decoding directly into the data structure we actually want, rather than using an intermediary representation for the JSON structure and having another layer of conversion code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm open to exploring it! It would be nice to streamline it - we have a lot of one-off JSON parsing logic like this all over.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have one which is just converted into a different data structure? I could convert that to ocaml-decoders to get a taste and show you how it's look.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine there are probably a ton of opportunities here: https://github.com/onivim/oni2/blob/5d88ef8e359789c650698ba02e2c5daf7ad664a8/src/Extensions/ExtHostProtocol.re

That handles a lot of the JSON serialization <-> deserialization coming in/out of the extension host. A great place to simplify!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll bring in this change for now, since it gets us to the next layer of issues with vscode-python - but interested to see how we can improve with ocaml-decoders.


module Engine = {
[@deriving (show, yojson({strict: false, exn: true}))]
type t = {vscode: string};
Expand All @@ -24,7 +44,7 @@ module Engine = {
type t = {
name: string,
version: string,
author: [@default None] option(string),
author: [@default None] Author.t,
displayName: [@default None] option(LocalizedToken.t),
description: [@default None] option(string),
publisher: [@default None] option(string),
Expand Down