Still Maintained?

[Marviel]

Hey Mechrophile -- sweet project!

I notice that the library hasn't been updated in around 2 years as of the writing of this post.

Is this because it's still feature-perfect? Or is this library in a more volatile state?

Haven't dug in, but loving the ability to both validate/coerce simultaneously, so I'm hoping it's the former 😄

[Defunctionalize]

Hey Luke! Much appreciated! I'm out just now but I'll be back in the office soon. Will reach out then

…

On Mon, Jul 30, 2018, 14:29 Luke Bechtel ***@***.***> wrote: Hey Mechrophile -- sweet project! I notice that the library hasn't been updated in around 2 years as of the writing of this post. Is this because it's still feature-perfect? Or is this library in a more volatile state? Haven't dug in, but loving the ability to both validate/coerce simultaneously, so I'm hoping it's the former 😄 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACYO9sD4C14hdUoUlbyyaRp2U9JDOhRJks5uL1CFgaJpZM4Vm7vx> .

[jjtolton]

Awesome!!! On Mon, Jul 30, 2018 at 2:33 PM Tyler Tolton <[email protected]> wrote:

…

Hey Luke! Much appreciated! I'm out just now but I'll be back in the office soon. Will reach out then On Mon, Jul 30, 2018, 14:29 Luke Bechtel ***@***.***> wrote: > Hey Mechrophile -- sweet project! > > I notice that the library hasn't been updated in around 2 years as of the > writing of this post. > > Is this because it's still feature-perfect? Or is this library in a more > volatile state? > > Haven't dug in, but loving the ability to both validate/coerce > simultaneously, so I'm hoping it's the former 😄 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#21>, or mute the thread > < https://github.com/notifications/unsubscribe-auth/ACYO9sD4C14hdUoUlbyyaRp2U9JDOhRJks5uL1CFgaJpZM4Vm7vx > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ6b81Gomow2ikUPSzLRzn-VXzz5TDAHks5uL1FugaJpZM4Vm7vx> .

[Defunctionalize]

Is this because it's still feature-perfect? Or is this library in a more volatile state?

The answer is "more or less both. kind of." I'll bashfully admit that I've been working in Clojure professionally for a while, and I have left schemagic in its pre 1.0 state. If I were to update this library to 1.0 there are a couple things that I would do.

1. Possibly split schemagic.web into its own library (thats a feature set that should be independently versioned, and it's conceivable that it needs to be updated to keep pace with new flask versions)
2. do some benchmarking to provide some stats about what application load it supports
3. give the code some exercise on newer python versions to make sure everything is copacetic.

That said, the data structure validation and coercion code is very stable for the web case and certainly fast enough for normal data volume. It's using a simple recursive "coerce everything in this data structure and if any of the coercions fail, fail the validation" strategy that doesn't rely on any volatile assumptions. The core code was designed to have an extremely small footprint and it should therefore be pretty easy to track down any problems that arise.

Thanks much for reaching out, Luke! This message has got me interested in shaking out the cobwebs on schemagic

[Marviel]

@Mechrophile thanks for the detailed response!

At this point we're looking into cerberus, because even though it's buried in the docs they have coercion.

What I don't like about that library is that it requires the schema definition to be super verbose, even in cases where you don't take advantage of the ability to specify things like "max", "min", and other optional parameters for more detailed validation.

What would be super optimal is the simplicity of this repo, mixed with the optional configurabilty of cerberus (tons of detailed built-in validators, optional key-value options, Python 2/3 support, etc). Basically -- don't require super-verbose schema unless the user is going to take advantage of that.

I know that's probably outside the scope of what can be easily captured within a single, neat recursive call, though 😬

On the other side of things, it appears that with so many users Cerberus is probably stuck with its current verbose style, without the abilty to add in much syntactic sugar (i.e. lists can be represented with [..] and not {"type": "list"}.... etc.

Anyway -- just dumping my thoughts on the topic here, should you be interested in re-thinking this library to be even more awesome than it currently is. :)