librelist archives

Updates from DjangoCon

From:

Armin Ronacher

Date:

2010-09-11 @ 23:27

Hey,

As you might know I was the last week at DjangoCon :)  It's always 
interesting to hear how others are solving certain things.

While some might not agree, but Django is doing incredible well both in 
terms of implementation and handling the community.  I think we have to 
be very careful dismissing ideas from Django land because in many areas 
they are far ahead of anyone else.

Here an incomplete list of things that became clear in discussions where 
Flask must improve:

- static file handling.  The naive approach of exposing one folder
   automatically is quick and simple, but also dirty and does not work
   well with S3, GAE and other setups.  There has to be an option to
   move static stuff to subdomains and other services.

- Flask-Script is hugely useful and should be mentioned on the
   official Flask documentation.  Ideally that thing would also provide
   a "flask" script that looks for a flaskscriptfile.py in parent
   directories.  "flask runserver" from foo/bar finds
   foo/flaskscriptfile.py or something similar and executes stuff from
   there.  Having this as some kind of convention makes it easier to
   integrate other things into Flask.  (Flask-Celery for instance.)

- Modules need tons of love.  And probably also a new name.

- Instantiating modules multiple times should be less hackish.
   Currently if a module is registered multiple times that thing is
   actually registered multiple times on the URL map and no actual
   function is executed when that happens.  You can't have a per-module
   activation config for instance.

- The extensions attribute on the application.  Finally.

- Flask-Deploy.  It would totally kick-ass if you just have to run a
   command and it heads over your application to a remote server, set
   up a virtualenv etc.  Maybe even support silverlining.

I don't have concrete plans for all things yet, but that is roughly the 
things I have on the roadmap for upcoming versions.


Regards,
Armin

> While some might not agree, but Django is doing incredible well both in
> terms of implementation and handling the community.  I think we have to
> be very careful dismissing ideas from Django land because in many areas
> they are far ahead of anyone else.

Completely agree.



> - Flask-Deploy.  It would totally kick-ass if you just have to run a
>   command and it heads over your application to a remote server, set
>   up a virtualenv etc.  Maybe even support silverlining.

Please do not have flask decide to create virtual environments, or if
so, make it optional.  Many prefer buildout.

OT:  I would love to hear why zc.buildout seems like such a pariah,
off the list if necessary.  It virtualizes as well as virtualenv. I
can build my own python, be I so inclined, and if absolutely
necessary, I could build vim or emacs  into it as well to benefit from
the pythonpath.  Why is virtualenv preferred?  Can someone make the
case to an agnostic?

Silverlining:  It would make much more sense to support GAE
deployments rather than silverlining at this time, no?

Flask-Deploy:
Even if it were to just create a directory, say './deploy and create
the files needed to deploy on many platforms, would be the best tool I
have ever heard of.   It would be such a refreshing change to look
into that directory and see configs and .wsgi files for four or five
different types of deployments, to be as flexible in deployment, as in
choice of data store.

Pylons got this right.  I don't hear them worrying about deployment
like Django does.

In fact, there is a phrase that perfectly sums up web development in
python, and the stated goals of Flask.
A preference for  a 'microframework'  with 'no lock in' , that allows
you to 'choose what you need'  means  TIMTOWTDI.
Flask should support that.

>
> OT:  I would love to hear why zc.buildout seems like such a pariah,
> off the list if necessary.  It virtualizes as well as virtualenv. I
> can build my own python, be I so inclined, and if absolutely
> necessary, I could build vim or emacs  into it as well to benefit from
> the pythonpath.  Why is virtualenv preferred?  Can someone make the
> case to an agnostic?

Ideally,  you should be able to decide whatever you prefer. I find
fabric + virtualenv works fine with my Flask and Django deployments
but YMMV. This sort of thing should probably be framework independent
like WSGI.

>
> Silverlining:  It would make much more sense to support GAE
> deployments rather than silverlining at this time, no?
>

I think this was intended as an example.

> Flask-Deploy:
> Even if it were to just create a directory, say './deploy and create
> the files needed to deploy on many platforms, would be the best tool I
> have ever heard of.   It would be such a refreshing change to look
> into that directory and see configs and .wsgi files for four or five
> different types of deployments, to be as flexible in deployment, as in
> choice of data store.
>
> Pylons got this right.  I don't hear them worrying about deployment
> like Django does.

Maybe "deployment recipes". Paste does this, it doesn't need to be
Pylons-specific. Just make a recipe for e.g. a simple Flask app with a
wsgi config, basic XHTML layout templates, whatever.

> but YMMV. This sort of thing should probably be framework independent
> like WSGI.

Agreed 100%

> Maybe "deployment recipes". Paste does this, it doesn't need to be
> Pylons-specific. Just make a recipe for e.g. a simple Flask app with a
> wsgi config, basic XHTML layout templates, whatever.

Paste* was the second reason I began to wonder about Django,decisions.
It is so damn handy, to create any type of skeleton.

The first, and ultimately convincing reason was when I tried Eric
Holscher's debugging techniques, and said to myself "Wait, WTF is this
Werkzeug thing?"  ;)

On Sat, 2010-09-11 at 16:27 -0700, Armin Ronacher wrote:
> Hey,
> 
> As you might know I was the last week at DjangoCon :)  It's always 
> interesting to hear how others are solving certain things.
> 
> While some might not agree, but Django is doing incredible well both in 
> terms of implementation and handling the community.  I think we have to 
> be very careful dismissing ideas from Django land because in many areas 
> they are far ahead of anyone else.
> 
> Here an incomplete list of things that became clear in discussions where 
> Flask must improve:
> 
> - static file handling.  The naive approach of exposing one folder
>    automatically is quick and simple, but also dirty and does not work
>    well with S3, GAE and other setups.  There has to be an option to
>    move static stuff to subdomains and other services.

I say keep the naive default setup but provide a clear way to redefine
url_for('static'); Flask-Deploy could recursively symlink static
directories for the app and all modules to a single place for serving
via a more capable web server, or it could generate mod_wsgi
configuration with aliases for all the static directories.

It's a big win with Flask to be able to get up and prototyping quickly
without having to deal with a monstrous settings.py.

> 
> - Flask-Script is hugely useful and should be mentioned on the
>    official Flask documentation.  Ideally that thing would also provide
>    a "flask" script that looks for a flaskscriptfile.py in parent
>    directories.  "flask runserver" from foo/bar finds
>    foo/flaskscriptfile.py or something similar and executes stuff from
>    there.  Having this as some kind of convention makes it easier to
>    integrate other things into Flask.  (Flask-Celery for instance.)

But don't obscure it too much. How about

manager.add_command(flaskext.celery.some_command)

I prefer typing this over extensions having automatic support for
Flask-Script.

> 
> - Modules need tons of love.  And probably also a new name.
> 
> - Instantiating modules multiple times should be less hackish.
>    Currently if a module is registered multiple times that thing is
>    actually registered multiple times on the URL map and no actual
>    function is executed when that happens.  You can't have a per-module
>    activation config for instance.
> 
> - The extensions attribute on the application.  Finally.
> 
> - Flask-Deploy.  It would totally kick-ass if you just have to run a
>    command and it heads over your application to a remote server, set
>    up a virtualenv etc.  Maybe even support silverlining.
> 
> I don't have concrete plans for all things yet, but that is roughly the 
> things I have on the roadmap for upcoming versions.
> 
> 
> Regards,
> Armin

1) Flask-Script should not do anything magically IMHO like look up a
file in a parent directory. It's the kind of "look for something in
some directory" magic that Django uses that I wanted to get away from.

2) Flask-Deploy would be excellent if it had Fabric integration.

3) Modules. What is really the difference between a Module and an App
? The only (conceptual) difference is that an app is an "executable"
or "root" module.

Why not get rid of modules altogether and just make it possible to
join apps together ? e.g.

app = Flask(__name__) # root app

from my_other_app import another_app

app.register_app(another_app)

app.run() # or pass app to wsgi or whatever

4) Static file handling needs to be improved, maybe by adding a Static
module/app like so:

app = Flask(__name__)
app.register_module("/media/", Static())
app.register_module("/s3", S3Static())

and so on. That would allow for different static backends.


On 12 September 2010 09:39, Dag Odenhall <dag.odenhall@gmail.com> wrote:
> On Sat, 2010-09-11 at 16:27 -0700, Armin Ronacher wrote:
>> Hey,
>>
>> As you might know I was the last week at DjangoCon :)  It's always
>> interesting to hear how others are solving certain things.
>>
>> While some might not agree, but Django is doing incredible well both in
>> terms of implementation and handling the community.  I think we have to
>> be very careful dismissing ideas from Django land because in many areas
>> they are far ahead of anyone else.
>>
>> Here an incomplete list of things that became clear in discussions where
>> Flask must improve:
>>
>> - static file handling.  The naive approach of exposing one folder
>>    automatically is quick and simple, but also dirty and does not work
>>    well with S3, GAE and other setups.  There has to be an option to
>>    move static stuff to subdomains and other services.
>
> I say keep the naive default setup but provide a clear way to redefine
> url_for('static'); Flask-Deploy could recursively symlink static
> directories for the app and all modules to a single place for serving
> via a more capable web server, or it could generate mod_wsgi
> configuration with aliases for all the static directories.
>
> It's a big win with Flask to be able to get up and prototyping quickly
> without having to deal with a monstrous settings.py.
>
>>
>> - Flask-Script is hugely useful and should be mentioned on the
>>    official Flask documentation.  Ideally that thing would also provide
>>    a "flask" script that looks for a flaskscriptfile.py in parent
>>    directories.  "flask runserver" from foo/bar finds
>>    foo/flaskscriptfile.py or something similar and executes stuff from
>>    there.  Having this as some kind of convention makes it easier to
>>    integrate other things into Flask.  (Flask-Celery for instance.)
>
> But don't obscure it too much. How about
>
> manager.add_command(flaskext.celery.some_command)
>
> I prefer typing this over extensions having automatic support for
> Flask-Script.
>
>>
>> - Modules need tons of love.  And probably also a new name.
>>
>> - Instantiating modules multiple times should be less hackish.
>>    Currently if a module is registered multiple times that thing is
>>    actually registered multiple times on the URL map and no actual
>>    function is executed when that happens.  You can't have a per-module
>>    activation config for instance.
>>
>> - The extensions attribute on the application.  Finally.
>>
>> - Flask-Deploy.  It would totally kick-ass if you just have to run a
>>    command and it heads over your application to a remote server, set
>>    up a virtualenv etc.  Maybe even support silverlining.
>>
>> I don't have concrete plans for all things yet, but that is roughly the
>> things I have on the roadmap for upcoming versions.
>>
>>
>> Regards,
>> Armin
>
>
>
>

On Sun, Sep 12, 2010 at 3:58 AM, Dan Jacob <danjac354@gmail.com> wrote:

> 1) Flask-Script should not do anything magically IMHO like look up a
> file in a parent directory. It's the kind of "look for something in
> some directory" magic that Django uses that I wanted to get away from.
>
>
IMO Flask-* should not do any magically. I came to Flask because I became
too frustrated with Django's magic. It's impressive in screencasts and
tutorials but it's a pain when you want to do something that isn't a blog,
or a CRUD application.





> 2) Flask-Deploy would be excellent if it had Fabric integration.
>
> 3) Modules. What is really the difference between a Module and an App
> ? The only (conceptual) difference is that an app is an "executable"
> or "root" module.
>
> Why not get rid of modules altogether and just make it possible to
> join apps together ? e.g.
>
> app = Flask(__name__) # root app
>
> from my_other_app import another_app
>
> app.register_app(another_app)
>
> app.run() # or pass app to wsgi or whatever
>
> 4) Static file handling needs to be improved, maybe by adding a Static
> module/app like so:
>
> app = Flask(__name__)
> app.register_module("/media/", Static())
> app.register_module("/s3", S3Static())
>
> and so on. That would allow for different static backends.
>
>
> On 12 September 2010 09:39, Dag Odenhall <dag.odenhall@gmail.com> wrote:
> > On Sat, 2010-09-11 at 16:27 -0700, Armin Ronacher wrote:
> >> Hey,
> >>
> >> As you might know I was the last week at DjangoCon :)  It's always
> >> interesting to hear how others are solving certain things.
> >>
> >> While some might not agree, but Django is doing incredible well both in
> >> terms of implementation and handling the community.  I think we have to
> >> be very careful dismissing ideas from Django land because in many areas
> >> they are far ahead of anyone else.
> >>
> >> Here an incomplete list of things that became clear in discussions where
> >> Flask must improve:
> >>
> >> - static file handling.  The naive approach of exposing one folder
> >>    automatically is quick and simple, but also dirty and does not work
> >>    well with S3, GAE and other setups.  There has to be an option to
> >>    move static stuff to subdomains and other services.
> >
> > I say keep the naive default setup but provide a clear way to redefine
> > url_for('static'); Flask-Deploy could recursively symlink static
> > directories for the app and all modules to a single place for serving
> > via a more capable web server, or it could generate mod_wsgi
> > configuration with aliases for all the static directories.
> >
> > It's a big win with Flask to be able to get up and prototyping quickly
> > without having to deal with a monstrous settings.py.
> >
> >>
> >> - Flask-Script is hugely useful and should be mentioned on the
> >>    official Flask documentation.  Ideally that thing would also provide
> >>    a "flask" script that looks for a flaskscriptfile.py in parent
> >>    directories.  "flask runserver" from foo/bar finds
> >>    foo/flaskscriptfile.py or something similar and executes stuff from
> >>    there.  Having this as some kind of convention makes it easier to
> >>    integrate other things into Flask.  (Flask-Celery for instance.)
> >
> > But don't obscure it too much. How about
> >
> > manager.add_command(flaskext.celery.some_command)
> >
> > I prefer typing this over extensions having automatic support for
> > Flask-Script.
> >
> >>
> >> - Modules need tons of love.  And probably also a new name.
> >>
> >> - Instantiating modules multiple times should be less hackish.
> >>    Currently if a module is registered multiple times that thing is
> >>    actually registered multiple times on the URL map and no actual
> >>    function is executed when that happens.  You can't have a per-module
> >>    activation config for instance.
> >>
> >> - The extensions attribute on the application.  Finally.
> >>
> >> - Flask-Deploy.  It would totally kick-ass if you just have to run a
> >>    command and it heads over your application to a remote server, set
> >>    up a virtualenv etc.  Maybe even support silverlining.
> >>
> >> I don't have concrete plans for all things yet, but that is roughly the
> >> things I have on the roadmap for upcoming versions.
> >>
> >>
> >> Regards,
> >> Armin
> >
> >
> >
> >
>

Hi,

The file lookup would be not any more magical than how hg finds its repo 
or how git does that. Fabric and make are also working that way.

Regards,
Armin

(sent from a handheld device)

On 13.09.2010, at 18:41, Drew Vogel <drewpvogel@gmail.com> wrote:

> On Sun, Sep 12, 2010 at 3:58 AM, Dan Jacob <danjac354@gmail.com> wrote:
> 1) Flask-Script should not do anything magically IMHO like look up a
> file in a parent directory. It's the kind of "look for something in
> some directory" magic that Django uses that I wanted to get away from.
> 
> 
> IMO Flask-* should not do any magically. I came to Flask because I 
became too frustrated with Django's magic. It's impressive in screencasts 
and tutorials but it's a pain when you want to do something that isn't a 
blog, or a CRUD application.
> 
> 
> 
>  
> 2) Flask-Deploy would be excellent if it had Fabric integration.
> 
> 3) Modules. What is really the difference between a Module and an App
> ? The only (conceptual) difference is that an app is an "executable"
> or "root" module.
> 
> Why not get rid of modules altogether and just make it possible to
> join apps together ? e.g.
> 
> app = Flask(__name__) # root app
> 
> from my_other_app import another_app
> 
> app.register_app(another_app)
> 
> app.run() # or pass app to wsgi or whatever
> 
> 4) Static file handling needs to be improved, maybe by adding a Static
> module/app like so:
> 
> app = Flask(__name__)
> app.register_module("/media/", Static())
> app.register_module("/s3", S3Static())
> 
> and so on. That would allow for different static backends.
> 
> 
> On 12 September 2010 09:39, Dag Odenhall <dag.odenhall@gmail.com> wrote:
> > On Sat, 2010-09-11 at 16:27 -0700, Armin Ronacher wrote:
> >> Hey,
> >>
> >> As you might know I was the last week at DjangoCon :)  It's always
> >> interesting to hear how others are solving certain things.
> >>
> >> While some might not agree, but Django is doing incredible well both in
> >> terms of implementation and handling the community.  I think we have to
> >> be very careful dismissing ideas from Django land because in many areas
> >> they are far ahead of anyone else.
> >>
> >> Here an incomplete list of things that became clear in discussions where
> >> Flask must improve:
> >>
> >> - static file handling.  The naive approach of exposing one folder
> >>    automatically is quick and simple, but also dirty and does not work
> >>    well with S3, GAE and other setups.  There has to be an option to
> >>    move static stuff to subdomains and other services.
> >
> > I say keep the naive default setup but provide a clear way to redefine
> > url_for('static'); Flask-Deploy could recursively symlink static
> > directories for the app and all modules to a single place for serving
> > via a more capable web server, or it could generate mod_wsgi
> > configuration with aliases for all the static directories.
> >
> > It's a big win with Flask to be able to get up and prototyping quickly
> > without having to deal with a monstrous settings.py.
> >
> >>
> >> - Flask-Script is hugely useful and should be mentioned on the
> >>    official Flask documentation.  Ideally that thing would also provide
> >>    a "flask" script that looks for a flaskscriptfile.py in parent
> >>    directories.  "flask runserver" from foo/bar finds
> >>    foo/flaskscriptfile.py or something similar and executes stuff from
> >>    there.  Having this as some kind of convention makes it easier to
> >>    integrate other things into Flask.  (Flask-Celery for instance.)
> >
> > But don't obscure it too much. How about
> >
> > manager.add_command(flaskext.celery.some_command)
> >
> > I prefer typing this over extensions having automatic support for
> > Flask-Script.
> >
> >>
> >> - Modules need tons of love.  And probably also a new name.
> >>
> >> - Instantiating modules multiple times should be less hackish.
> >>    Currently if a module is registered multiple times that thing is
> >>    actually registered multiple times on the URL map and no actual
> >>    function is executed when that happens.  You can't have a per-module
> >>    activation config for instance.
> >>
> >> - The extensions attribute on the application.  Finally.
> >>
> >> - Flask-Deploy.  It would totally kick-ass if you just have to run a
> >>    command and it heads over your application to a remote server, set
> >>    up a virtualenv etc.  Maybe even support silverlining.
> >>
> >> I don't have concrete plans for all things yet, but that is roughly the
> >> things I have on the roadmap for upcoming versions.
> >>
> >>
> >> Regards,
> >> Armin
> >
> >
> >
> >
> 

On 13 September 2010 20:15, Armin Ronacher <armin.ronacher@active-4.com> wrote:
> Hi,
> The file lookup would be not any more magical than how hg finds its repo or
> how git does that. Fabric and make are also working that way.

What would it actually gain ?

>> The file lookup would be not any more magical than how hg finds its repo or
>> how git does that. Fabric and make are also working that way.

The easiest way to solve this sort of problem is to add a --magic
switch to the script, causing it to dump it's assumptions.  I can't
believe I just thought of this.  This would have saved our sanity back
in the perl days...

I'm not sure how this is magic though.  The alternative is to specify
everything in an .ini file.

On 14 September 2010 01:03, kevin beckford <chiggsy@lazyweb.ca> wrote:
>>> The file lookup would be not any more magical than how hg finds its repo or
>>> how git does that. Fabric and make are also working that way.
>
> The easiest way to solve this sort of problem is to add a --magic
> switch to the script, causing it to dump it's assumptions.  I can't
> believe I just thought of this.  This would have saved our sanity back
> in the perl days...
>
> I'm not sure how this is magic though.  The alternative is to specify
> everything in an .ini file.
>

The problem is however that it's not clear how or where a Flask app is
"run". Your app module could be called anything, it can be a single
file or nested in a package, etc. You may have more than one app in a
module and so on.

If we were to embed Flask-Script into the app, perhaps the answer is
to override app.run(). At the moment this just runs the development
server, but why not instead have it run the Flask-Script manager ?

At the moment you have this:

app = Flask(__name__)
# configure your app

manager = Manager(app)
# add more commands

if __name__ == "__main__":
    manager.run()

Instead:

app = Flask(__name__)
# configure your app

# add commands: e.g.
@app.manager.command
def createdb():
   ....

if __name__ == "__main__":
     app.run()  # shortcut for app.manager.run()

In data domenica 12 settembre 2010 10:58:56, Dan Jacob ha scritto:
> 1) Flask-Script should not do anything magically IMHO like look up a
> file in a parent directory. It's the kind of "look for something in
> some directory" magic that Django uses that I wanted to get away from.

+1  I fully endorse!

> 3) Modules. What is really the difference between a Module and an App
> ? The only (conceptual) difference is that an app is an "executable"
> or "root" module.

The App is the executable, the Module contains the code that do things.
A Module collaborate with others modules, an App is only the root and the 
logic (scripts and modules) that gather all in a response. IMHO they are very 
different things.

Davide Muzzarelli
www.dav-muz.net

>> 3) Modules. What is really the difference between a Module and an App
>> ? The only (conceptual) difference is that an app is an "executable"
>> or "root" module.
>
> The App is the executable, the Module contains the code that do things.
> A Module collaborate with others modules, an App is only the root and the
> logic (scripts and modules) that gather all in a response. IMHO they are very
> different things.
>

Maybe. But in almost all respects an app and a module are identical,
and this I think is the cause of much confusion.

In data domenica 12 settembre 2010 14:05:11, Dan Jacob ha scritto:
> Maybe. But in almost all respects an app and a module are identical,
> and this I think is the cause of much confusion.

I'm sorry but I don't catch the similarity.

An app load the route engine, the template engine, the database engine and the 
settings one time for all the modules, so each module have a common place with 
other modules in order to write less and reuse the code. The app call the 
different parts of a module in order to make a response.
Through the configuration or extra code a developer can change the settings and 
how to load the things.
An app is thin.

A module have the route rules, the templates, the model objects, the views and 
so on. The modules are called by one app in order to prepare a response.
Through the configuration or extra code a developer can change the behavior and 
parts of the module.
A module cover an aspect (News, Events, Pages, Comments etc.).

If a developer use a module as an app he gets these cons:
- multiple loading of libraries for each app that consume memory, really a bad 
thing for a VPS or an hosting;
- impossibilty to use modules in different manner, the developer can only use 
external modules "as is" or completely fork it (examples: rewrite a module 
just for change the route rules, rewrite a module just for a subdomain or a 
domain, rewrite a module just for change a view, and so on). Bad code reuse.

Personally, I built different websites with the same modules that I have in a 
shared package that I use like a simple library: each website use the modules 
in different manners so each website have their custom urls (very important for 
SEO) and often custom views (every website have its own requirements).
I do this absolutly without forks and the code is lean.
Working with more than few websites copying and forking modules will become 
soon an impossible thing to maintain. My experience.

A side note: actually it is possible to do this reuse of modules in Django so 
Pinax and other external libraries are born, but in Flask is not possible. 
IMHO, making a module as an app will restrict even more.

Am I wrong?

Davide Muzzarelli
www.dav-muz.net

> A module have the route rules, the templates, the model objects, the views and
> so on. The modules are called by one app in order to prepare a response.
> Through the configuration or extra code a developer can change the behavior and
> parts of the module.
> A module cover an aspect (News, Events, Pages, Comments etc.).

Modules have nothing to do with models. Models are tangental to Flask.

That said, it might be a good idea to use signals to register certain
events with modules inside the app or request lifecycle.

> Personally, I built different websites with the same modules that I have in a
> shared package that I use like a simple library: each website use the modules
> in different manners so each website have their custom urls (very important for
> SEO) and often custom views (every website have its own requirements).
> I do this absolutly without forks and the code is lean.
> Working with more than few websites copying and forking modules will become
> soon an impossible thing to maintain. My experience.

Being able to change URLs for a module on the fly may be handy.

>
> A side note: actually it is possible to do this reuse of modules in Django so
> Pinax and other external libraries are born, but in Flask is not possible.
> IMHO, making a module as an app will restrict even more.
>

Personally, having used Django quite heavily, I have found the only
useful, reusable apps have been the low-level ones such as debug and
south - model-heavy apps like Pinax are great for cookie-cutter sites,
but those have been quite rare in my experience.

That said, what Django does get right is greater configurability with
routes, and modules need to be easier and more flexible on that front
(that, and static URLs).

In data domenica 12 settembre 2010 14:56:09, Dan Jacob ha scritto:
> Modules have nothing to do with models. Models are tangental to Flask.
> 
> [...]
> 
> Personally, having used Django quite heavily, I have found the only
> useful, reusable apps have been the low-level ones such as debug and
> south - model-heavy apps like Pinax are great for cookie-cutter sites,
> but those have been quite rare in my experience.
> 
> That said, what Django does get right is greater configurability with
> routes, and modules need to be easier and more flexible on that front
> (that, and static URLs).

I don't figure what you think is implemented. It is interesting. Could you 
explain how run the things and a sample directory structure?

Davide Muzzarelli
www.dav-muz.net

> - static file handling.  The naive approach of exposing one folder
>   automatically is quick and simple, but also dirty and does not work
>   well with S3, GAE and other setups.  There has to be an option to
>   move static stuff to subdomains and other services.

Maybe a built in utility function for static file versioning would be
usefool, too?
Something like:

def static(filename):
    """Adds content versioning to static files by appending a last modification
    timestamp to the url"""
    filepath = os.path.join(os.path.dirname(__file__), 'static', filename)
    last_modification = '%d' % os.path.getmtime(filepath)
    return url_for('.static', filename=filename) + '?' + last_modification


> - Flask-Deploy.  It would totally kick-ass if you just have to run a
>   command and it heads over your application to a remote server, set
>   up a virtualenv etc.  Maybe even support silverlining.

While it is true that something like Flask-Deploy isn't suitable for every
corner case it would certainly be helpful for beginners or people with
a simple server setup to quickly get the application live. People with a
complex server setup and experience still can deploy their application
the way they want - Flask-Deploy wouldn't take this possibility away,
I guess :). As for myself I can say that reading and understanding how to
deploy Flask with distribute, virtualenv, fabric and setting up the server
properly took me several days although the docs and information was
good. If there had been Flask-Deploy it would have made my life much
easier :).


Eugen

Could someone elaborate on this?  I'm currently working on a re-usable 
module, and I've seen this sentiment a few times on the list.

Does it mainly have to do with multiple instantiations?

On Sep 11, 2010, at 7:27 PM, Armin Ronacher wrote:

> 
> 
> - Modules need tons of love.  And probably also a new name.
> 
> 
> Regards,
> Armin

There is an option to move static stuff to subdomains and other services in
handling static file is very very useful for really world! +1

Things like Flask-Script supported in official is a good idea. +1


2010/9/12 Armin Ronacher <armin.ronacher@active-4.com>

>
> - static file handling.  The naive approach of exposing one folder
>   automatically is quick and simple, but also dirty and does not work
>   well with S3, GAE and other setups.  There has to be an option to
>   move static stuff to subdomains and other services.
>
> - Flask-Script is hugely useful and should be mentioned on the
>   official Flask documentation.  Ideally that thing would also provide
>   a "flask" script that looks for a flaskscriptfile.py in parent
>   directories.  "flask runserver" from foo/bar finds
>   foo/flaskscriptfile.py or something similar and executes stuff from
>   there.  Having this as some kind of convention makes it easier to
>   integrate other things into Flask.  (Flask-Celery for instance.)
>

In data domenica 12 settembre 2010 01:27:33, Armin Ronacher ha scritto:
> As you might know I was the last week at DjangoCon :)  It's always
> interesting to hear how others are solving certain things.

I think so :)

> - Flask-Script is hugely useful and should be mentioned on the
>    official Flask documentation.

+1

>    Ideally that thing would also provide
>    a "flask" script that looks for a flaskscriptfile.py in parent
>    directories.  "flask runserver" from foo/bar finds
>    foo/flaskscriptfile.py or something similar and executes stuff from
>    there.  Having this as some kind of convention makes it easier to
>    integrate other things into Flask.  (Flask-Celery for instance.)

This method will restrict the possibility to use it with different custom file 
locations?

> - Modules need tons of love.  And probably also a new name.

What are your thoughts about? Actually this is my principal focus.

> - The extensions attribute on the application.  Finally.

+1

> - Flask-Deploy.  It would totally kick-ass if you just have to run a
>    command and it heads over your application to a remote server, set
>    up a virtualenv etc.  Maybe even support silverlining.

+0
I think that I will not use it because there are not standard methods to 
deploy, but I could be wrong... Actually, for me, Fabric's commands are enough 
easy and fast to use.

Davide Muzzarelli
www.dav-muz.net

In data domenica 12 settembre 2010 14:56:09, Dan Jacob ha scritto:
> Modules have nothing to do with models. Models are tangental to Flask.
> 
> [...]
> 
> Personally, having used Django quite heavily, I have found the only
> useful, reusable apps have been the low-level ones such as debug and
> south - model-heavy apps like Pinax are great for cookie-cutter sites,
> but those have been quite rare in my experience.
> 
> That said, what Django does get right is greater configurability with
> routes, and modules need to be easier and more flexible on that front
> (that, and static URLs).

I don't figure what you think is implemented. It is interesting. Could you 
explain how run the things and a sample directory structure?
And about the amount of RAM consumed (Model structure vs. multiple Apps)?

Davide Muzzarelli
www.dav-muz.net

> And about the amount of RAM consumed (Model structure vs. multiple Apps)?

I wouldn't have thought it would make a difference. Do you have any
benchmarks to show us ?

In data giovedì 16 settembre 2010 10:09:23, Dan Jacob ha scritto:
> > And about the amount of RAM consumed (Model structure vs. multiple Apps)?
> 
> I wouldn't have thought it would make a difference. Do you have any
> benchmarks to show us ?

If the difference is few KBs there is not a problem. 90% of my projects are 
constrained in a VPS or in a hosting. But there are problems if there are 
multiple instances of the libraries (database, forms etc.), one for each app.

If I know how you mean this app structure I could develop a spike solution and 
make a benchmark.

I also do not understand how translate a Django project with many modules in 
your multi-app idea, because I do not know how you intend to implement it.

I will try to implement it in order to find differences. Could you explain it?

Davide Muzzarelli
www.dav-muz.net

> I also do not understand how translate a Django project with many modules in
> your multi-app idea, because I do not know how you intend to implement it.
>

I don't know. I wouldn't recommend on how to translate any project
without seeing the source code and structure first. Django has such a
different approach anyway I'm not sure a 1:1 translation would work
(are you still using the Django ORM ?). I'd probably just split the
apps up into separate packages for models/views/helpers etc to start
with and work from there. Otherwise it's like building any large
Python project - start with modules, when they get to big/ungainly
split into packages, and so on.

The only reasons I'd go multi-app is if there are several instances of
the same app (for example, you have a project management system, one
install for each customer) or a separate site using the same
models/database (for example, one public site, one admin site). In
either case the same rules apply on memory consumption as any other
Python web application.