Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
next-starter-blog
NEXT.js starter blog with MDX, Tailwind CSS, TypeScript, and pre-configured Development Environment with Husky, Lint Staged and Commitizen
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues.
Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM...
Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.
Low dependency analysis is one of the reasons I like Flask[0].
[0] https://github.com/pallets/flask/blob/main/setup.py
Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB.
Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and two timezone related backports (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite.
1. https://github.com/django/django/blob/60a7bd89860e504c0c33b0...
Since it's not mentioned, we also use as TODOs/issue-tracker.
https://github.com/terrastruct/d2/issues
We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code.
I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.
I don't think it is as soupy as you say.
Flask is split up into a few Pallets projects - Flask, Werkzeug, Markupsafe, Click, itsdangerous, Jinja2 - but they're all from the same stable group. This split makes them more useful as independent libraries, rather than one big framework.
Ditto two more (Alembic and SQLAlchemy) are also from a very stable group. It would be nice if Alembic used Jinja2 instead of Mako, of course, but it's a dev-time dependency and so it's lower risk in my opinion.
I agree that at the thing Django does (forms + a SQL database) it does it with fewer dependencies than Flask. But that doesn't mean Flask has loads of dependencies; it has an appropriate number for the task you're doing. I was more comparing Flask to actual dependency soup ecosystems[0].
[0] https://github.com/rizkimcitra/next-starter-blog/blob/main/p...
Related posts
- How to Deploy a Fast API Application to a Kubernetes Cluster using Podman and Minikube
- Analysing FastAPI Middleware Performance
- Ask HN: High quality Python scripts or small libraries to learn from
- AutoCodeRover resolves 22% of real-world GitHub in SWE-bench lite
- Building a streaming SQL engine with Arrow and DataFusion