Release schedule to V3?

[adamdavis40208]

https://pypi.org/project/jsonschema/#history

What is the roadmap for moving the stable release to 3? Do you all need any help?

Thanks for all the hard work you put into this!

[Julian]

Hi, thanks so much!

I'd say it's probably about a month before a stable release, there's some non-critical-functionality I'd still love to get out before a real release, and want to give some more time for any feedback on the alpha.

Could definitely use a hand on a few things! Definitely if any of the open issues look like the sort of thing you might be interested in I'm more than happy to chat about how to implement them. And there's quite a few open PRs unfortunately, some of which are waiting for a review, which is another area that definitely could use a hand on!

[opethe1st]

I would also love to help. Your library is awesome! I was gushing as I was using it :) 👍

[Julian]

:) thanks to you both!

If the offer to help is open, #191 and #460 are 2 fairly self contained issues (the former being quite old at this point).

#191 is pretty straightforward on how to approach I suspect -- a test is needed, and then presumably something is calling like extendleft when it should be calling extendright or something.

And #460 would also be great to start on before a 3.0 release so that the deprecation could be part of the release. The first step on that one would be the always fun task of deprecation, which is still quite hard to do in Python given that we still don't have a great library for it. So ideally someone can propose something for that issue that's fairly small.

Happy to give further pointers of course (though yeah my time comes in bursts at this point).

[tmontes]

@Julian,

First and foremost, thanks for sharing jsonschema: I've been exploring it recently, evaluating its possible application in a near future project and I quite like it, in particular the detailed validation failures it produces.

Having said that, I'd like to target draft-06 of the spec which, I understand, is included in the current version 3 alpha, not published on PyPI yet.

Wanting to contribute in moving things forward, I found this issue, which I understand is closed, but seemed like the best place to chime in on... Maybe it could be kept open until v3 is released? Or, alternatively, all pending v3 issues/PRs could be assigned to the v3.0.0 milestone, like #133 is? What do you say?

Question: are the above mentioned issues the ones that need work before v3 is deemed releasable? Maybe others? Can you please pinpoint a kind of "roadmap" to v3?

Again thanks.

[Julian]

Hi! Great, thanks so much for the offer!

There are basically 2 things blocking a stable release -- the first is something like #509, which is the kind of thing I knew would happen but it did take nearly 2 months for someone to file a bug on a pretty basic thing that had changed which needed investigation, which makes me still a bit queezy -- just giving time to people to try out the new releases.

The second set of things are the unchecked items in this comment.

Nearly all are fairly minor -- e.g., error properties (e.g. ValidationError.context) for the new validators (e.g not, contains, if, propertyNames etc.) need tests and there's a small bit of functionality that's intentionally "broken" / underimplemented there for them until there are tests. It's a minor issue but one that likely should be fixed before a real release. And then really, there are 2 issues there that have been discovered that are "worrying" enough to be true blockers -- one is that Draft 7 introduced a time format -- unfortunately Draft 3 also had a time format, but it meant a totally different thing. This basically has revealed that FormatChecker has some bad ideas in it, namely some things are more global than they should be. Fixing that is likely to be at least slightly intrusive -- either a new parameter to jsonschema.validators.create needs to be added, or in the worst case, backwards compatibility on FormatChecker might need to be broken. And the second thing that's been (worryingly) discovered is how to deal with boolean schemas. jsonschema supports all drafts, and all drafts do not have boolean schemas. So one thing that has definitely been broken and needs fixing is that, given the current implementation, Draft 3 for instance now accepts True and False as schemas, which is very incorrect. So that needs to be fixed. The most likely way to fix that is to add a validators_from_schema (function) argument to jsonschema.validators.create which takes a schema (whatever it might be for a given draft) and produces from it an iterable of validators, which then for Draft 3 should not allow True or False, and for Draft 6/7 should.

Definitely would appreciate help on any or all of the above as small, self-contained patches! And happy to elaborate further on anything.

[tmontes]

@Julian,

Thanks for the feedback. Let me try to rephrase that in my own words -- for you to please confirm my understanding -- and then propose a way forward:

Pending issues for v3:

• Something like Error in early release 3.0.0.a3 but not in 2.6.0 #509.
  Given that the issue is closed, I wonder what exactly you mean by that. Do you mean that the original code using jsonschema.validators.create should have worked and that using jsonschema.validators.extend instead shouldn't have been needed? Is it a documentation issue instead? Or is it just wanting to give "time to people to try out the new releases"?
• The unchecked items in #337.
  Should an individual issue be created for each of them, and then linked in front of each checkbox?
• time format in Draft 3 vs Draft 7.
  Should an individual issue be created for this?
• How to deal with boolean schemas: Draft 3 is accepting True/False schemas but shouldn't.
  Should an individual issue be created for this?

As you may guess, the first thing I'm trying to understand is the big picture. I think the last two topics should have issues of their own. As for the unchecked items in #337, not so sure (I would do it in a project of mine, but understand that you may not want to). :)

I would then assign these issues to the existing v3.0.0 milestone -- this will help sharing of progress towards v3 and focusing contributor collaboration.

Where I stand:

• I'm no JSON Schema expert: I've just been studying it recently.
• I'm very proficient in Python so that won't be a limitation.
• I'm not familiar with the codebase at all; like I mentioned, I've been playing around with it from a "user" perspective.
• I'll be happy to contribute but would love some guidance for the sake of productivity: in particular, if possible, a high level overview of the code / components would be very welcome! :)

What I already did:

• Forked and cloned the repo.
• Tried setting up a development environment: couldn't find docs on this, but went with pip install -e . followed by pip install -r test-requirements.txt for running tests with trial; noticed tox.ini but didn't go with tox, for now.
• Tried out the "Draft 3 accepting True/False schemas":
  • 2.6.0
    • Draft3Validator(schema=True) raises an AttributeError: 'bool' object has no attribute 'get'.
  • 37671ac
    • Draft3Validator(schema=True) raises AttributeError: 'bool' object has no attribute 'get'
    • Draft6Validator(schema=True) returns a <...locals.Validator> object.
  • Did I misunderstand your note on this topic?

I'll stand by, for now, hoping we can:

• Organize the pending issues towards v3.
• Identify which contributions I'll be able to complete effectively.

[Julian]

Thanks! I like that strategy.

Something like #509.
Given that the issue is closed, I wonder what exactly you mean by that. Do you mean that the original code using jsonschema.validators.create should have worked and that using jsonschema.validators.extend instead shouldn't have been needed? Is it a documentation issue instead? Or is it just wanting to give "time to people to try out the new releases"?

So I actually should (mean to) re-open that. It's behavior that differs unintentionally between the two versions. So the OP of the issue got what they wanted and closed it, but the underlying "why is there different behavior" still needs addressing, it sounds likely to me that there's a bug in the new type checker changes, though there are a few skipped tests in the test suite that might be the same bug. So yeah not a doc issue, it's a behavior change that needs fixing or at very least confirming is intentional.

The unchecked items in #337.
Should an individual issue be created for each of them, and then linked in front of each checkbox?
time format in Draft 3 vs Draft 7.
Should an individual issue be created for this?
How to deal with boolean schemas: Draft 3 is accepting True/False schemas but shouldn't.
Should an individual issue be created for this?

I didn't personally have a reason to turn them into issues given that at the end of the day they're just tasks that need to be done, and presumably I was going to be the one to do them, but if it makes things easier for you or you can think of any other reason to do so, feel free to.

I would then assign these issues to the existing v3.0.0 milestone -- this will help sharing of progress towards v3 and focusing contributor collaboration.

Great!

I'll be happy to contribute but would love some guidance for the sake of productivity: in particular, if possible, a high level overview of the code / components would be very welcome! :)

Happy to! Will probably have to come back to this in a bit (few hours, or tomorrow maybe) and write up some useful tips that would help.

Did I misunderstand your note on this topic?

See the (currently skipped == failing) test marked jsonschema.tests.test_validators.TestDraft3Validator.test_False_is_not_a_schema_even_if_you_forget_to_check for precisely what I mean here, hopefully that helps.

And super super appreciated, especially being as organized as that last comment was :)

Oftentimes the hardest part of helping a new contributor (or contributions in general) is making small, self contained, organized, agreed upon changes that I can then easily review and merge, so being organized and making sure we are clear on exactly what things mean is amazingly helpful.

Thanks again!