librelist archives

Flask Roadmap

From:

Armin Ronacher

Date:

2010-07-28 @ 00:08

Hi,

Over the last couple of weeks the question about a roadmap for Flask 
came up fairly often.  The reason why I did not share my plans on that 
so far is that Flask is directly related to another project which did 
not have a Roadmap so far: Werkzeug.

What I found out with Flask the last few months is that it's actually a 
lot easier to maintain small libraries with frequent releases than 
larger libraries.  Werkzeug has not seen any releases lately, mainly 
because I planned to do a 1.0 release at one point.

Now however I want to get a couple of more releases into Werkzeug to fix 
some of the issues I think are still there.  So the roadmap for Flask is 
now directly linked to the roadmap of Werkzeug.

Here what I have in mind for these two projects:

Next Werkzeug Release:

   - deprecate Werkzeug's internal template engine.  With that, the
     integrated debugger should also stop using templates altogether
     or switch to Jinja2.  Have not considered that yet.  At one point
     it should be replaced with Flickzeug, but there is currently no
     real plan about the future of Flickzeug I'm afraid.  This project
     would need a lot of support.
   - deprecated werkzeug.contrib.kickstart and
     werkzeug.contrib.jsrouting.  Both of which should become separate
     projects on PyPI in a werkzeugext namespace, similar to how Flask
     extensions work.
   - improve the routing system so that it has an actual parser for
     the route definitions instead of using eval() on arguments.

Next Flask Release:

   - Consider adopting some kind of extension registry.  Ali Afshar
     proposed a dictionary attached to the application where extensions
     can register themselves, but I am not sure if this will be the
     final solution.
   - rework Flask internally to support instance directories.  This might
     also mean that templates, static files and more will be loaded from
     an internal virtual filesystem.  This would need some brainstorming
     as well.

I am posting this here because if you want to help out, there are a 
couple of things to chose from :)  The easiest ones are the Werkzeug 
issues because the Flask ones currently involve a lot of trying stuff 
out and ditching it again.  I already did some experiments on that and 
so far I haven't found a solution I am happy with myself.


Regards,
Armin

On 28 July 2010 01:08, Armin Ronacher <armin.ronacher@active-4.com> wrote:

>
>   - Consider adopting some kind of extension registry.  Ali Afshar
>     proposed a dictionary attached to the application where extensions
>     can register themselves, but I am not sure if this will be the
>     final solution.

I wasn't suggesting a dict or even necessarily registering extensions
themselves on the app, more of a way by which extensions can store
arbitrary data on the app, (though I guess it's probably the same
thing).

Hi,

Le 28/07/2010 02:08, Armin Ronacher a écrit :
> rework Flask internally to support instance directories.

Where can I read more about this? (What does it mean?)

Regards,
-- 
Simon Sapin

Hi,

On 7/28/10 1:28 PM, Simon Sapin wrote:
> Where can I read more about this? (What does it mean?)
I am currently in the process of writing a specification for this.  Will 
put that on github then.


Regards,
Armin

Hi Armin,

Thank you for the reasons for the missing roadmap for the flask project. 
Now I understand.

Regards,

Stéphane

On 07/28/2010 02:08 AM, Armin Ronacher wrote:
> Hi,
> 
> Over the last couple of weeks the question about a roadmap for Flask 
> came up fairly often.  The reason why I did not share my plans on that 
> so far is that Flask is directly related to another project which did 
> not have a Roadmap so far: Werkzeug.
> 
> What I found out with Flask the last few months is that it's actually a 
> lot easier to maintain small libraries with frequent releases than 
> larger libraries.  Werkzeug has not seen any releases lately, mainly 
> because I planned to do a 1.0 release at one point.
> 
> Now however I want to get a couple of more releases into Werkzeug to fix 
> some of the issues I think are still there.  So the roadmap for Flask is 
> now directly linked to the roadmap of Werkzeug.
> 
> Here what I have in mind for these two projects:
> 
> Next Werkzeug Release:
> 
>    - deprecate Werkzeug's internal template engine.  With that, the
>      integrated debugger should also stop using templates altogether
>      or switch to Jinja2.  Have not considered that yet.  At one point
>      it should be replaced with Flickzeug, but there is currently no
>      real plan about the future of Flickzeug I'm afraid.  This project
>      would need a lot of support.
>    - deprecated werkzeug.contrib.kickstart and
>      werkzeug.contrib.jsrouting.  Both of which should become separate
>      projects on PyPI in a werkzeugext namespace, similar to how Flask
>      extensions work.
>    - improve the routing system so that it has an actual parser for
>      the route definitions instead of using eval() on arguments.
> 
> Next Flask Release:
> 
>    - Consider adopting some kind of extension registry.  Ali Afshar
>      proposed a dictionary attached to the application where extensions
>      can register themselves, but I am not sure if this will be the
>      final solution.
>    - rework Flask internally to support instance directories.  This might
>      also mean that templates, static files and more will be loaded from
>      an internal virtual filesystem.  This would need some brainstorming
>      as well.
> 
> I am posting this here because if you want to help out, there are a 
> couple of things to chose from :)  The easiest ones are the Werkzeug 
> issues because the Flask ones currently involve a lot of trying stuff 
> out and ditching it again.  I already did some experiments on that and 
> so far I haven't found a solution I am happy with myself.
> 
> 
> Regards,
> Armin

Hi, sounds great.

"Internal virtual file-system" does not sounds very "micro framework" to me
though.

Thanks, Jim.

On 28 July 2010 01:08, Armin Ronacher <armin.ronacher@active-4.com> wrote:

> Hi,
>
> Over the last couple of weeks the question about a roadmap for Flask
> came up fairly often.  The reason why I did not share my plans on that
> so far is that Flask is directly related to another project which did
> not have a Roadmap so far: Werkzeug.
>
> What I found out with Flask the last few months is that it's actually a
> lot easier to maintain small libraries with frequent releases than
> larger libraries.  Werkzeug has not seen any releases lately, mainly
> because I planned to do a 1.0 release at one point.
>
> Now however I want to get a couple of more releases into Werkzeug to fix
> some of the issues I think are still there.  So the roadmap for Flask is
> now directly linked to the roadmap of Werkzeug.
>
> Here what I have in mind for these two projects:
>
> Next Werkzeug Release:
>
>   - deprecate Werkzeug's internal template engine.  With that, the
>     integrated debugger should also stop using templates altogether
>     or switch to Jinja2.  Have not considered that yet.  At one point
>     it should be replaced with Flickzeug, but there is currently no
>     real plan about the future of Flickzeug I'm afraid.  This project
>     would need a lot of support.
>   - deprecated werkzeug.contrib.kickstart and
>     werkzeug.contrib.jsrouting.  Both of which should become separate
>     projects on PyPI in a werkzeugext namespace, similar to how Flask
>     extensions work.
>   - improve the routing system so that it has an actual parser for
>     the route definitions instead of using eval() on arguments.
>
> Next Flask Release:
>
>   - Consider adopting some kind of extension registry.  Ali Afshar
>     proposed a dictionary attached to the application where extensions
>     can register themselves, but I am not sure if this will be the
>     final solution.
>   - rework Flask internally to support instance directories.  This might
>     also mean that templates, static files and more will be loaded from
>     an internal virtual filesystem.  This would need some brainstorming
>     as well.
>
> I am posting this here because if you want to help out, there are a
> couple of things to chose from :)  The easiest ones are the Werkzeug
> issues because the Flask ones currently involve a lot of trying stuff
> out and ditching it again.  I already did some experiments on that and
> so far I haven't found a solution I am happy with myself.
>
>
> Regards,
> Armin
>

Hi,

On 7/28/10 9:15 AM, JimG wrote:
> "Internal virtual file-system" does not sounds very "micro framework" to
> me though.
It does to me :)


Regards,
Armin