Is this a dead project? #162
Comments
|
Whether @xeipuuv continues to drive this or not, I'm also interested in whether new JSON Schema drafts will be implemented (we will be publishing draft-07 hopefully by the end of october, with support for The community for this project is much bigger than the other Go implementation (plus there are related libraries such as the one to generate schemas from Go code), so I would prefer to use this. |
|
Indeed. I'm fairly new to projects this big in the open source community. How does the community deal with situations like this? Does someone just fork it and start maintaining a fresh new project? I am very interested in being a contributor considering my project (https://github.com/samsung-cnct/jsonsvalidator) strongly depends on it and our internal project will be strongly depending on my project. |
|
In @xeipuuv's defense, two of the three PRs that have been open for a while are in states where the PR submitter probably needs to take action. The very long gap between draft-04 and draft-06 (the next draft to have significant validation or core implementation impact) has put a lot of JSON Schema projects in a bit of an odd situation, where they were basically complete before and suddenly are not. |
|
Fair enough, but I haven't seen @xeipuuv make any significant comments to any issues of late either. That is probably my biggest concern where abandonment seems plausible given the amount of time that has gone by for any kind of updates on this project. |
|
I welcome PRs and keep an eye on this project so that they can be accepted/merged. My free time is very limited and unfortunately I can't tackle the issues popping up. |
|
@xeipuuv it is good to see you're alive and well. 😁 If the PRs that currently exist do not satisfy you then please leave comments on them so the authors can do what's necessary to make them satisfying. I have an open PR I submitted just a couple of days ago. I would love to know why it won't be merged. I've left numerous comments, lately, to other's issues and would love to hear more feedback on my comments as well, but I've been met with nothing but silence. I totally get not having a bunch of time. I have five kids, a wife, a mortgage, and three jobs. I still have to keep my commitments, or if I can't handle them then I have to find a way to shift priorities around while still keeping my commitments. If you're over-subscribed, please help the community by allowing us to help you. We just need to know what you need for that assistance. This project is awesome. You've rocked it! We know that because so many people/organizations rely on it. So we are counting on you to continue to make it successful. I will gladly help out where I can. I'm new to go development so my help will likely be minimal at first. All I need from you is your expectations. |
|
@xeipuuv is #128 in the "not satisfying" boat? If so, could I get guidance on what could be done to make it "satisfying"? No one has responded but i'm happy to submit it again as my own PR if @ricardomaraschini won't rebase himself. I don't want to do so unless I know it will be worthwhile. It is a really nice contribution and is needed to fully support the spec's definition of the format keyword; it would be unfortunate to let it slip by and die. Also It's used in https://github.com/opspec-io/sdk-golang so would be great to get it in upstream proper rather than maintaining fork. |
|
No problems with the feature we talked about in #128, though it is in a pending state because it has conflicts. I'd gladly accept the PR as soon as it is ready. |
|
There seem to be a couple of PRs that fix bugs that should be satisfactory because they are bug-fixes not features. I would think bug-fixes would not necessarily require any more "satisfaction" to @xeipuuv than the bug fixes work and are sane. #161 might be one of these (I'm still waiting for feedback), as well as #150. @xeipuuv you didn't fully respond to all of the concerns in this thread: "If the PRs that currently exist do not satisfy you then please leave comments on them so the authors can do what's necessary to make them satisfying." |
|
@handrews I feel like your expertise and involvement would be ideal to take on this project. |
|
@xeipuuv thanks! While I'd love to advise on the work and help with any questions or feedback on the specification, I'm really not familiar with Go as a programming language. However, I may have a colleague or two at work who would be interested (we use a lot of Go and JSON Hyper-Schema, and I have been recommending this package, which is why I've kept an eye on issues and PRs). I can check and see if anyone with suitable Go experience has time available. My own coding is more on the JavaScript side these days. |
|
I understand. I invited you as one anyway, I guess a spec expert won't hurt ;) And more generally, if a Go developer, preferably someone who already contributed to this project, feels like being a contributor too. Just let me know. |
|
I would love to be a contributor, as I already stated. I am a developer, just new to Go. Perhaps there could be a concerted effort between a few of us to help out. I would love to be a part of the team. |
|
@xeipuuv @handrews |
|
Hello. I have been considering too the status of various go JSON tools. |
|
Following my previous post, those interested would find a quick tour of published packages with a similar objective. This one is definitely the only one standing out.
|
|
@fredbi You missed https://github.com/santhosh-tekuri/jsonschema which is the only Go implementation that supports draft-06 that I know of (last commit 1 m; issues 0; open/total PRs 0/1; contributors 1). This project here is by far the strongest, but I know that in order for my team to use it going forwards we will need to find someone to bring it up to supporting draft-06 and soon draft-07. |
|
Yeah you're right. Thanks. And there are probably some more out there... PS: a few days ago, I was pretty much disappointed by a similar pattern with the related problem of generating go structures from JSON schema. Again, 9 available packages or so (most in a 0/0/1 formation). I tested carefully 6 of them. Most worked on more or less complicated examples. None did provide a full JSON schema support. Few are active projects. Now I am gonna test JSON validators the same way. Keep you posted with results soon. |
Yeah, that's why I'd love it if we can pull together enough volunteers to move this forward. It is very hard to support all features of JSON Schema in strongly statically typed languages, and there is some effort towards defining a subset of features that code (and other) generators MUST support for interoperability. The JSON Schema validation vocabulary is intended to provide full validation functionality, which is a very different use case from generation. |
|
Honestly, it would be helpful to have a corpus of schemas and instance data where using a given tool to parse and then serialize would be expected to give semantically-identical output. As edge cases crop up, throw them in the corpus so they can be leveraged by other implementations. (This would have a side-effect of incentivizing including serialization functionality in order to take advantage of a ready pool of unit test fodder, but that's not a bad thing...) |
|
I have to be honest that it's getting to the point where it might not be a bad idea to fork and extend this project with a robust group of contributors so that it can move forward. I've had a PR open against this project for months with NO mention from @xeipuuv about why he won't merge it. This is the strongest json validation tool in golang but it's stuck at draft 4. I know that @xeipuuv is busy! I'd be really interested to see if anyone has thoughts about these ideas? |
|
I appreciate the matrix above. You missed one other: https://github.com/samsung-cnct/jsonsvalidator 4mo, nil, 2, 0 I'm the maintainer of that one. The fun thing is that it uses this project as its main library. A few others from the matrix that use this as its main library are: https://github.com/johandorland/gojsonvalidator |
|
ping |
|
@notjames Yes I think this repo should be forked to remain active. go is really lacking a robust set of tools for JSON, and atm, it is really much of an annoyance for those who have chosen go as their main development language. Personally I decided to help the team maintaining go-swagger (https://github.com/go-swagger/go-swagger) as it is more closely related to my use-case (that is, generating go types, then serializing JSON in go constructs, and not just validating JSON schema rules). This project is using https://github.com/mailru/easyjson as its underlying JSON serializer powerhorse. |
|
@fredbi Thank you for your comment. @xeipuuv hasn't been around for months but he did merge PRs three days ago (awesome). I have a fork @ notjames/gojsonschema, but probably am going to hold off since @xeipuuv made some progress. I'm still thinking I'm going to politely take over. I'll wait and see if @xeipuuv has anything to say about it (like really strong objections or some such). I'd much rather have the ability to collaborate along with a few others so that we can leave the project here and just tend to it properly. |
|
I wouldn't say this project is dead, it just needs a few extra maintainers. I'd be against forking this project as it only leads to more fragmentation and since this is the oldest and most widely used JSON Schema library in the golang ecosystem it will take a very long time before everyone moves over to a new repository (if ever). If @xeipuuv feels comfortable with it I'd be happy to help out maintaining this project and adding draft6 and draft7 to its feature set. I am pretty familiar with the code base after the recent PR I spent way too much time on, although I don't have any previous experience in maintaining a GitHub repo. |
|
@johandorland I absolutely agree with you. I've not been eager to fork it but even @xeipuuv seemed hesitant to add maintainers since I started this thread. I had a very simple PR up for literally months before it was merged. Movement on this project has been supremely slow. I'm all in favor of having this remain the main project, but we have to have the ability to let the project proceed in a timely manner. I've also thrown my towel into volunteer as a maintainer. |
|
Hey all,
I'm also interested writing a robust interface for traversing json pointers in decoded go types, which is a set of patterns I think the go community needs. While writing our implementation the beginnings of this interface has emerged, and I'm excited to see where we can take it. After auditing what's available around the web I'm not convinced anyone has taken the time to work out a robust implementation in Go, which makes me sad. So we've started to work on our own implementation, and I'm going to shamelessly promote those two repos (qri-io/jsonschema and qri-io/jsonpointer) here, and invite all of you to pile on if you feel the code we're putting out is up to snuff. Yes, we're currently guilty of the We will be working to continually improve this for our own needs, and would love it if you find this stuff useful. I can promise you that we'll do everything to respond to PR's/issues within reasonable time frames, invite anyone who's interested & courteous to become contributors, and hand over control of the repo to an active maintainer if for whatever reason we can't support the project in the future. That being said, I don't want to take from @xeipuuv's efforts on this library to date. I wouldn't and won't encourage anyone who doesn't have our needs to switch away from using this project. But I do think the go community deserves a solid implementation of this wonderful spec with timely maintenance. @handrews I want to thank you & all contributors for the incredible json-test-suite. I'm amazed at how helpful this repo has been, and only wish other specs came with such a great test suite 😉. @notjames in particular I'd love to see if we can't help solve your needs, both in terms of communication and code. @johandorland I very much respect and share your desire for coalescing around a smaller number of implementations. Writing a new package is not a decision I take lightly. Thanks! |
|
@johandorland I just added you to the list of collaborators on gojsonschema and its sub repos: gojsonpointer and gojsonreference. Feel free to improve these projects, build a team of core collaborators and move to a draft6/7. Thank you for taking the lead on this project and moving it in the right direction. |
|
@xeipuuv @johandorland As I've said before I am not in a position to take a lead on any of these Go project. I am more than happy to answer spec questions and be a general JSON Schema consultant, but a.) I don't know Go b.) I don't have time to learn another programming language right now, c.) leading the specification work takes up more time than I have as it is. I would prefer not to have merge rights on any of these repos as people have already asked me to merge things and I am not qualified to evaluate PRs except in the most general "does this seem to be doing the right thing if I eyeball it as pseudocode" sort of way. |
|
Thank you for adding me @xeipuuv . I'll try to take good care of your projects. |
|
@johandorland sounds like it's time to close this issue with an answer of "nope, it's not dead" :-) I'm really happy to see you step up, and feel free to at-mention me for spec concerns, or join the JSON Schema slack channel. Here's an invite link (that anyone can use, copied from our web site): |
Looking at the pulse of this project, there has been no significant progress on PRs in roughly nine months. We have an important project which depends on this project. @xeipuuv are you going to continue to be the primary maintainer of this project or would you be interested in transferring the project to a new maintainer, a primary group of maintainers, or some other method which will allow the proper development of this project to continue mainstream?
The text was updated successfully, but these errors were encountered: