brandur
json_schema and json-schema
Hello @brandur (owner of json_schema) and @iainbeeston (owner of json-schema)
Any chance of you guys getting together and merging to create a single canonical json schema gem? I've got a project which, because of various dependencies, ends up pulling in both gems -- and using each gem in different parts.
(I spent a long time trying to track down an issue, looking at the documentation for one gem while tracing through the code from the other one, getting mighty confused because I didn't even realize there were two different gems! Eventually I noticed "the json schema gem" was included twice in Gemfile.lock:
json-schema (2.4.1)
json_schema (0.3.1)
..and at first I thought it was a bug in bundler -- the distinction between dash and underscore distinction is remarkably subtle when you're not looking for it!)
Anyway, I have no deep knowledge of either project, nor their history, architecture, or philosophy. And so no idea how feasible it would be. Nor of course whether you'd be interested in merging. So this is probably a longshot... but I, for one, would be happy to see you pooling your talents and creating a single best-of-both gem that everyone used everywhere.
Thanks for listening!
Just wanted to point out I'm not the owner of json-schema - it's owned by the ruby-json-schema organisation. You probably want to include @hoxworth @pd and @RST-J too.
Incidentally, can you explain what error you were seeing? I imagine it might be a namespace clash, in which case we can certainly try to resolve that so there's no contradiction
@iainbeeston I think you just included the other guys, thanks :) I should have written that you are an owner rather than implying you are the owner. I considered cross-posting an issue on ruby-json-schema/json-schema, but didn't want to overly spam; and I just picked you as a listed owner on rubygems and most recent contributor.
I should clarify, my error wasn't itself due to having both gems loaded. It seems that both gems can work comfortably side-by-side in the same app. I haven't seen any namespace clashes.
My issue is simply the confusion that arose because of unknowingly having two different gems loaded -- especially when their names are so similar. And when they are loaded implicitly as dependencies of other gems.
My confusion story: In developing my app, I was getting an error from json_schema that I didn't quite understand because I'm a JSON schema newbie. To try to understand the error, I mistakenly read the json-schema docs -- which of course didn't explain the json_schema error. With the docs being apparently useless, I naturally turned to the source. I used bundle show to go to one of them (I already forget which), still not knowing there were two in my app. I then inserted breakpoints, etc., and got mighty confused when some parts of my app managed to load and validate schemas without hitting the breakpoints. Note that my app wasn't itself directly calling either json_schema or json-schema -- it was calling other libraries that in turn called one or the other -- so I wasn't starting at an obvious entry point.
Anyway, that led me to a serious head-slapping moment, and wishing that for something as core as json schema support there be one canonical gem that everybody would use.
Ah I see. I'm not sure there's much we can do about that, and even if we did it's quite possible that someone could make a "jsonschema" gem or some other combination in the future. I'm sure @brandur had good reasons for developing his own gem rather than using json-schema, and diversity is (usually) a good thing, right?
We could always add a note to our readme file explaining the difference between the two gems? Or the alternatives available?
Also, this is probably going to be less of an issue in the future, as json-schema has started adding external dependencies, so the two gems should look fairly distinct within your Gemfile.lock
I have to agree with Iain - multiple implementations generally is a good thing. The naming may be confusing, but to be honest I'm happy @brandur named it what he did rather than "lipstick" or "pants" or some other non-descript library name.
I might add a separate section to our readme that lists alternative implementations, to hopefully avoid these confusions.
Yeah, multiple implementations is often a good thing -- but for something that might be considered 'core', having just one that everybody can rely on rather than a bunch of disparate ones also has some advantages.
I'm curious what @brandur will have to say about all this.
Anyway, thanks for commenting. And thanks to all for the handy gems!
Hey guys, good call bringing this up!
This confusion is on me: I originally wrote json_schema as a way to learn the spec better, and at the time purposely didn't do a lot of investigation as to what other libraries were already out there. When the project came to fruition, I noticed that the json_schema name was available, and not being a fan of obfuscated gem names, I pushed to it without knowing that there was already a json-schema in circulation. With its interface fresh in my mind, I replaced the pseudo-implementation that interagent/committee had at the time with it, and later pulled it into interagent/prmd as well without thinking too much of it. However, now that we're starting to see some external users on the gem, I can totally understand the frustration between the json_schema and json-schema naming.
In the long term, I'd certainly be up for consolidating with json-schema, although I probably won't commit to it right away because things seem to be working as they are today. I also did some bad things in json_schema like pull in V5's strictProperties because we needed this functionality internally, and I wouldn't expect json-schema to follow suit on a decision like that.
Sorry about the confusion! I'll try to keep convergence with json-schema in mind when making API design decisions.
@iainbeeston Hah, not even. Just some proposals on the table and a few other documents floating around:
- https://github.com/json-schema/json-schema/wiki/v5-Proposals
- https://github.com/fge/json-schema-validator/wiki/v5:-strictProperties
strictProperties is one that's sorely needed in my opinion though, so I'm hoping that it'll make it.
Perhaps this is going off topic slightly, but isn’t strictProperties just shorthand for setting both additionalProperties: false and required to all properties?=
Bring it up on the JSON schema mailing list, @iainbeeston :smile:
https://groups.google.com/forum/#!forum/json-schema
@iainbeeston @hoxworth Right, it's exactly the same as additionalProperties: false + required: [...]. I find using those to be a scaling issue though because with larger schemas it becomes very easy to add a property without also adding it to the required array, which leads to divergence over time.
I already have a thread on the mailing list open about this too! [1]
[1] https://groups.google.com/forum/#!topic/json-schema/VIbbc_CPSKs
@brandur If you do decide to use json-schema then I hope it'll be for the gem's own merits. We'd welcome any pull requests to make it better, especially from anyone who has managed to write a validator themselves!
@iainbeeston For sure! I just took a quick pass on the codebase, and I think your implementation is cleaner than mine anyway. I'll keep that in mind though, thanks!
Hey there folks! This is a necrobump for sure, but I'd like to see where we are.
Just to introduce myself a bit, I'm on the core JSON Schema team, and do a lot of work with JSON Schema at WeWork. We're doing a lot of contract testing through json_matchers, who have just switched from json-schema to json_schema, and I'm trying to work out where to send PRs in order to improve draft support.
Tooling suffered around the v4/v5 time because things stagnated on the JSON Schema project, but it's back with a fresh breath of life, and draft 8 is currently in the works. That means we need to get draft 6 and draft 6 and draft 7 supported.
Can we decide together which gem is going to be the one true gem, and channel efforts into that one? I'm happy to take things over if anyone has decided that JSON Schema or Ruby is not their thing anymore.
Hey Phil, thanks for following up again! The fact that the JSON schema project has fresh life and is moving forward again is absolutely awesome.
The first thing I want to note is that admittedly, I'm really not a choice candidate for maintaining a JSON schema project anymore. This gem used to be core to some processes at work, and I could justifiably spend time on the clock maintaining and improving it. I work elsewhere now, and although I think json_schema is still in our stack here, it makes up a much smaller part of it.
That said, I noticed that despite my relative inattention to this project, it still seems to have been getting more regular commits than json-schema. That might mean nothing at all, but it's possible that neither project has been getting close attention.
If it was decided that json-schema was the one true path forward, I think I'd still at least nominally maintain this gem. It's obvious from the ambient level of PRs I get in this project and a few derivative ones that they're still in at least moderately active use, and I don't want to pull out the rug from beneath those people.
Some possibilities for a gentle migration would be to build either (1) a shim layer that allowed this gem to call into the other while maintaining API compatibility, or (2) a clean and detail migration guide.
Lastly though, a somewhat interesting point came up in a PR from February that it seems that json_schema might have some performance benefits over json-schema. I didn't run the numbers myself at all, but I think if we were to decide to deprecate this project in favor of json-schema, someone should take at least a glance to validate or invalidate that claim, and if is true, we'd probably want to do some performance optimizations on json-schema.