librelist archives

Flask-Common extension?

From:

Ron DuPlain

Date:

2011-04-12 @ 12:25

Hi all,

Requesting comments, would you like to see a Flask-Common extension
(or "Flask-Utility") for code shared among extensions?  This is a
question mostly for extension developers, but I'd like to hear from
application developers, too.

I'm developing a new Flask-Solr extension and have a complete wrapper
around pysolr in a very small module (~50 lines of code) with full
app.config support for the pysolr.Solr API.  The next feature I'm
adding is pagination, and I simply lifted the Pagination class from
Flask-SQLAlchemy, which results in a common pagination API across at
least these 2 extensions and the usual benefits of code reuse (for
maintenance and faster extension writing).

I'd like to push the common code into its own extension so that
Flask-Solr users would not depend on SQLAlchemy.  That would make a
Flask-Common extension with only the Pagination class, which is
written generically and only refers to SQLAlchemy specifically in its
docstrings.  What else, if anything, would belong in a common
extension?

Flask-SQLAlchemy also has some current_app/request-context and
signaling logic that could potentially be pushed into a common
extension.  The docs and snippets have some other patterns, too.  I
imagine application developers could use such an extension but
anything not used in extensions is out of scope, in my opinion.

Let's hear from you!

Ron

Hi,

This may not apply to everything that would go into Flask-Common, but if 
the pagination is not Flask-specific, maybe it could go into Brownie?

http://packages.python.org/Brownie/

Regards,
-- 
Simon Sapin

I think we are going to start seeing more "Flask Util", "Flask Common",
"Flask Base" type of apps that inherently add "Enterprise" functionality to
flask.

Making common utility packages can be a challenge though since there is no
standard for database adapter in Flask, certain code ( like role based
access control ) only makes sense in its ability to bind to a backend store
(ie: sqlalchemy, mongodb, flat files, etc.)

I am even working on my own web_util package that contains lots of glue code

--
Thadeus




On Tue, Apr 12, 2011 at 10:03 AM, Simon Sapin <simon.sapin@exyr.org> wrote:

> Hi,
>
> This may not apply to everything that would go into Flask-Common, but if
> the pagination is not Flask-specific, maybe it could go into Brownie?
>
> http://packages.python.org/Brownie/
>
> Regards,
> --
> Simon Sapin
>

On Tue, Apr 12, 2011 at 13:09, Thadeus Burgess <thadeusb@thadeusb.com> wrote:
> I am even working on my own web_util package that contains lots of glue code.

Isn't that the point of a microframework? Wouldn't adding a "Common"
or "Base" package guide people into solving problems one way? Isn't
Flask is really about stepping back and letting you glue things
together in a way that works for you?

:)

On Tue, Apr 12, 2011 at 4:14 PM, Ian Langworth <ian@langworth.com> wrote:
> On Tue, Apr 12, 2011 at 13:09, Thadeus Burgess <thadeusb@thadeusb.com> wrote:
>> I am even working on my own web_util package that contains lots of glue code.
>
> Isn't that the point of a microframework? Wouldn't adding a "Common"
> or "Base" package guide people into solving problems one way? Isn't
> Flask is really about stepping back and letting you glue things
> together in a way that works for you?
>
> :)

I think you're discussing application development.  I'm looking
specifically at extension development, where there are common elements
among extensions.  (The requirements and intent of extensions
naturally lead to common implementations.)  Users benefit from common
APIs in extensions, and in my case, I'd like to use the pagination
implementation of Flask-SQLAlchemy without SQLAlchemy, hence a Common
package.

-Ron

Precisely, but most frameworks started out that way, and then grew into
monolithic beasts.

There are already tons of duplicated work happening for flask, I can count
several different Auth extensions posted to the group in the last month, and
even more on if searching on google. Most of them end up implementing the
same rules but use different names and combinations of function calls to
achieve the same end goal.

I'm not saying this is a bad thing, just pointing it out.\

--
Thadeus




On Tue, Apr 12, 2011 at 3:14 PM, Ian Langworth <ian@langworth.com> wrote:

> n't that the point of a microframework? Wouldn't adding a "Common"
> or "Base" package guide people into solving problems one way? Isn't
> Flask is really about stepping back and letting you glue things
> together in a way that wor
>