Move essential Sanic libraries under Sanic organisation

Moving forward
#1

Hi,

First time posting here :slight_smile:.
Inspired by a conversation I had with Ashley Sommer about a week ago after the latest major changes in Sanic have been pushed, also by this comment of his: https://github.com/huge-success/sanic/issues/1854#issuecomment-629607608. I think we should move the essential Sanic libraries under the Sanic organization. Examples of the libs I have on mind are:

  • A session library (e.g. sanic-session)
  • A form validation library (e.g. sanic-wtf)
  • A testing library (e.g. pytest-sanic)
  • Cors / Security headers library (e.g. sanic-cors)
  • (Maybe) Jinja rendering lib

What many frameworks that are more popular than Sanic have in common is that they all have these packages well maintained and even documented in their framework’s docs. I understand why Sanic would refuse to bake these libraires into the framework itself, but treating them strictly as 3rd party libs is a bad idea in my opinion, because the majority of Sanic users use atleast one of these libraries.

The main reason I’m writing this is because after the most recent changes, the request context API has been changed. This broke a lot of the libraries and applications out there. This would be fine if the Sanic library maintainers out there fixed the libs quickly and in a backward compatible manner to support the LTS version of Sanic. Unfortunately, many maintainers don’t have the time to do that, let alone merge fixes to the latest version only.

I know that both sanic-cors and pytest-sanic are already being maintained by two Sanic maintainers. So those are OK the way they are I guess. However, both pyx/sanic-wtf and xen/sanic_session are not, and their maintainers are apparently either don’t use the lib anymore or aren’t active. So, is the community open to having these two libraries moved under the Sanic org? I can handle the migration process myself and ensure that their current versions work for both the latest Sanic and LTS Sanic.

For full disclosure, I built another session library myself for Sanic that adds a bit to what sanic-session already provides (I couldn’t add these features to sanic-session because it would break its API).

Pros:

  • Provides both client side and session side sessions
  • Provides an auth session interface super-class
  • Supports having more than one session per request
  • Supports having more than one transport per session

Cons:

  • It’s a bit opinionated when it comes to the race-conditions avoidance mechanism, but that can be easily ignored/not used.

There’s also: pyx/sanic-cookiesession which is a very simple cookie session similar to what Flask provides natively.

Regardless of which libraries the community chooses to move under the Sanic organisation, I’ll be happy to lend a hand in maintaining them for the near future. I believe this will help developers build apps quicker and with more confidence because they won’t have to shop around for essential libraries and worry about their future and their maintanence status. Also, this will help keep these librarires secure and adhering to strict security standards. Especially that session and form handling are considered to be very exploitable parts in most applications. By doing this we help provide the stability needed for the community to grow.

Sorry for the long post :slight_smile:
Have a safe weekend

  • Sorry about not linking to all the libs I mentioned, new users can only post 2 links.
#2

Thanks for bringing this up. This is not the first time this has come up.

I just did a query for the number of pypi downloads for “sanic” packages in the last 360 days. Here is the top 10.

rank package downloads is core dev
1 sanic 1,307,732 Already in org
2 sanic-cors 515,531 YES
3 sanic-plugins-framework 472,487 YES
4 sanic-jwt 278,564 YES
5 pytest-sanic 252,491 YES
6 sanic-openapi 84,025 Already in org
7 sanic-prometheus 61,479
8 sanic-dispatcher 46,954 YES
9 sanic-session 44,337
10 sanic-jinja2 43,959
…
30 sanic-wtf 13,427

Full list

The biggest questions that I have are:

  1. How do we decide which projects make the cut?
  2. Who is going to maintain them?

Sanic has a number of core devs, but we all have other commitments. It is too much I think to ask them to take on projects that are not their own. So, I am not sure if this would mean bringing on more people to take over projects (like when @chenjr0719 took over sanic-openapi), or how this would look.

With that said, all the projects that are in the Top 5 with over 100K downloads already are managed by Sanic core developers.

I am not sure that I agree completely with your list since it starts making Sanic “opinionated”, which it should not be. Here are my thoughts on the libraries you mentioned:

  • sanic-cors - Already maintained by @ashleysommer, being the most used third-party package, and the importance of CORS to building modern APIs, I can see a clear argument for inclusion.
  • pytest-sanic - This one I think has probably had more conversation than any other. But, given the current state of testing and the release of sanic-test in the coming months, I think we should hold off and see how that plays out.
  • sanic-session - I think this is the only package under the 100K mark that might make sense. Session management is clearly important to stateful web applications, but it is only one type of methodology. Again, I am in favor of Sanic remaining unopinionated as to how an application should be built. There was a discussion a long time ago about bringing sanic-jwt under the umbrella. My hesitation back then was the same. Stateless applications are only one model. If one of those projects is adopted, I believe the other should. They are sort of Yin and Yang. My biggest hesitation would be that I have not interacted with its maintainer, and do not know how it would work. There are a number of details that I am a bit hesitant on, so I would want to keep that aside for now.
  • sanic-wtf - This is in no way a knock on the maintainer of this package, but I do not believe it belongs here at this time. It is, at its core, the synthesis of Sanic with a completely separate project. This sort of seems like a clear case for outside maintenance. Again, I do not want Sanic to take a stance as to how form data should be handled. While I would advocate that it is not a candidate for the umbrella, I am all for its inclusion in tutorial materials. We really should have a central place (probably on the front page of sanicframework.org) that has a bunch of tutorials and ideas on how to build with Sanic. It certainly could be a candidate for that.

With all of that said, I think the easiest way to handle this, or at least in the beginning, would be to take some of the top projects out there (the ones already being maintained by core developers) and bring those under.

#3

Part of the discourse security to help cut down on spamming. I bumped you up to a level 2 user.

1 Like
#4

Sanic being unopinionated is definitely one of the strongest selling points of the framework and I believe it should stay that way. I hope you didn’t think I meant to add these libs to Sanic core. I only meant for them to just be under Sanic org, not Sanic core. Adding Sanic JWT and Sanic Session under the Sanic organisation should be done with the goal of providing:

  1. API stability guarantee
  2. Long term maintenance guarantee
  3. Frequent security audits

However, the goal shouldn’t be:

  1. Enforce an opinion on how Sanic apps should be written.

I understand that there’s a limit to how much the Sanic maintainers can maintain. That’s why we should only be adding the libraries that are being most used. So, I’d like to thank you for researching this and making a nice list of the most used libraries. However, I think that the data should be taken with a tiny grain of salt. The reason why some libraries are ranking low might not correlate with their usability (or lack thereof) but be negatively affected by the fact that they are unmaintained e.g. SanicWtf. Now you ask, is there a better way than judging by the donwload rate. Probably not, but I’m going to take a wild guess and guess that the majority of Sanic users are coming from Flask or atleast are familiar with it. Providing some of the libraries that Flask natively maintains/have baked in e.g. (Flask-wtf, Jinja2, Session, Cookie session) will help a lot with the ease of development. I understand that it’s not the goal of Sanic to be the async version of Flask, there are other frameworks that aim for that e.g. Quart. But that’s not what I’m trying to get to. I just think that form handling, server side rendering and sessions are still very relevant in almost all backend frameworks. Most (if not all) successful frameworks have atleast a Session implementation being maintained natively. I agree, that sanic-wtf is not a good fit because it relies on a third party package that happens to be both 1. huge 2. synchronous. Same goes with Jinja.

The current maintainer of Sanic Session said that he doesn’t mind handing control of Sanic Session over to Sanic org. I’m familiar with its codebase and with the HTTP session API in general, so I can help maintain it for the foreseeable future should we agree on adding it under the Sanic org.

#5

@omarryhan Is this something you are still interested in?

#6

Sorry, what exactly?

If you mean maintaining sanic-session, then yeah, sure.
I’m only passively maintaining my Sanic apps and libs these days and am not actively working on them. So, I can do the same for any Sanic lib that I’m familiar with. Can’t promise you a lot of work though.

#7

Yes, I was looking back at this and determining if this was a strategy we wanted to adopt in 2021. But, I would be hesitant to bring it under the umbrella if I didn’t know there would be an active presence to maintain it. For example, sanic-openapi (which is under the umbrella) does not have great activity.

#8

That’s reasonable I guess. It doesn’t make sense to commit to a library long-term if there’s not much demand for it.

I’m not really sure what’s the protocol here. Should I somehow close this issue?