I agree. Having just finished a project with Flask, I ended up using no less than 8 million dependencies that I'd never heard of. "BYO everything" frameworks would be more appropriate, but even then, Flask brings with it an entire basement of sub-frameworks that I would argue make it so that you might as well just use a full-fledged framework like Django.
We use Flask for most things at my work; while it can have many dependencies, you usually don't need that many. Of course, you'll bring some in for certain tasks that your app needs to do, but especially for little doodads that just need to present a RESTful interface to some service, this usually isn't that many (or if there are many, they'll mostly have to do with the service, and not the app). Of course I don't know the details of your project. Either way, the advantage of a minimal framework like that is having the ability to easily install just what you need, so obviously that advantage is going to be less and less the more it is that you require it to do.
That's how it works with micro-frameworks, you pay for what you use. Now, it's not necessarily a problem, last time I checked, there was a decent list of functional Flask components. What do you feel is the advantage of having a huge 'contrib' folder, as long as the extensions are maintained? Because the advantage of not having an ORM bundled per default, and easily switching something like the templating language are pretty clear to me.
I have a django project that swapped out the django templates for mako. Mako templates are awesome to use. The problem is it becomes extremely difficult to use packages that have bundled templates of their own. I would think it'd be the same with flask, no?
Making assumptions about the available ORM and templating package allows 3rd party modules to do more of the work for you.
Jinja 2 is a Flask dependency, it is always configured, so that's a bad example (though I have to confess that I don't know how a Flash webapp with a different templating engine works with an extension using Jinja 2 for its views).
As for the ORM, yes and no. Many extensions have no need for it, but I think 99% of the others use SQLAlchemy, because it's the most popular. But if you want to make a website backed by a NoSQL solution, you don't need to depend on an ORM. Obviously, any extension based on SQLAlchemy will not work, but baking the ORM into the framework offers no solution to that.
..and every 3rd party module that contains their own models, which would be a very large number.
If you want to use SQL Alchemy, you're better off using a different framework. I'm currently trying to decide if this is the angle I should follow for my next project, which requires fairly sophisticated SQL (comparable to the django ORM anyway).
i just finished up a django project that also had "8 million" dependencies, the difference was a lot of them started with "django-" and some dependencies I would have liked to use were off the table.
But the fact they start with Django means you can expect
a) They will play nicely together.
b) There will be consistencies between the libraries.
c) Magic things like the Amdin interface will work.
(Is there any good replacement for Djangos Admin in another framework? Its amazingly powerful with a small amount of configuration).
> b) There will be consistencies between the libraries.
depends
> c) Magic things like the Amdin interface will work.
true
the workflow for this particular project seemed to go like this...
* get requirement from client
* search google for plugins/modules/etc
* choose some
* try to get them to work
* use them or fork them or find others
which to me seems a pretty roundabout way of getting something accomplished if you already know what needs to be done. it doesn't feel like programming, it feels to me like assembling things and testing/hoping there are no issues. I'd rather be programming.
