Re: [flask] Good read
- From:
- Ron DuPlain
- Date:
- 2011-10-19 @ 13:41
Executive summary: The boss raises valid points in software risk, each
of which can mitigated by a subtle shift in process where open source
packages are not treated as black boxes. Have the team conduct code
reviews, both of internal code and relevant open source projects, and
give developers some time to read the code they are using. It's not a
question of Flask vs Django or Python vs PHP, but whether the team is
able to make progress on new developments while maintaining an
existing code base with the resources they have. No software is
bug-free, in part because a bug does not exist without context.
Either give your team the process they need, or get a support contract
to keep your risk levels safe.
For further reading: see Cathedral and the Bazaar (1997-2001), by Eric
S. Raymond, freely available online. Raymond draws upon the
literature and from his own experience to discuss the very nature of
open versus closed software development processes, for production code
and not just open source.
I respond to specific points below. See also the extended post from
Adam Patterson.
On Wed, Oct 19, 2011 at 3:30 AM, Amirouche Boubekki
<amirouche.boubekki@gmail.com> wrote:
> There are several issues.
>
> The first question the boss asks is: isn't Flask a dead end ? The project is
> written and maintained by a student not a business. Armin can stop working
> on the project and Flask story could end.
The boss clearly hasn't met Armin.
Also, the Flask core team is larger than just Armin; perhaps we should
be more clear about that. Finally, the Pocoo Team has major
contributors to Flask maintenance who are not listed as committers on
the project. In fact, the Pocoo Team is likely a larger operation
than that of the boss'.
This point is key: a project backed by a business does not give you a
support contract any more than an engineering degree makes for more
maintainable code.
> Then comes the arguments about Flask vs Django. The boss see Django as the
> mainstream solution so it's difficult to explain where Flask is better.
> Arguing that Flask is better because it's better code, solve problems in a
> better way using proven solutions like SQLAlchemy don't talk to him. He
> wants examples of PHP->Flask experience or at least projects that use Flask
> for their business and if possible with same complexity as the ones he wants
> to re-build.
Flask is not Django, and last I checked, the Flask project has no
intention to replace Django.
For experiences in using Flask, reach out to the list or visit
http://flask.pocoo.org/community/poweredby/ and pick up the phone.
> In the link it's a Python->Python switch so their is a bunch of code that
> can be re-used, but in the case of PHP->Python only phpserialize can help in
> some places.
In my opinion, this is a systemic issue in too much reliance on a
framework. I personally avoid monolithic projects in favor of a
collection of focused, semantically versioned (semver.org) packages.
At some point, you can put your business logic into a
framework-independent library. That's up to your engineering team.
> Another reason not to use Flask is the lake of third party applications
> (third party extensions in Flask nomenclature). At my current job we heavily
> rely on third party code. This is a choice, it holds even if most of them
> were tweaked or re-written (which makes me think that it might not have been
> a good idea all the time.). In current Flask ecosystem what extensions are
> trying to bridge the gap between Flask as microframework and Django. But
> there is not goodie extensions like django-messages, django-favorites or
> anything that keeps you from writing more code and actually implement
> functionalities of the website and not the framework. Flask being ORM
> agnostic makes it harder to build extensions.
Biggest feature to me: Flask has listed and approved extensions.
Flask has a clear extension pattern which is very Pythonic (defined
via `import this`), approved/reviewed extensions (!!), a
well-documented extension review process, and a dedicated buildbot
running tests on every commit to the entire stack, the Flask core and
each listed extension.
Here is the buildbot, but its reporting facilities are currently not
ready for public use.
http://74.207.234.95:8010/builders
The fault for this buildbot not yet being public is entirely mine.
The user experience for the current reporting screens is entirely
lacking. The buildbot has a combinatorial matrix of:
* Python 2.5, 2.6, 2.7 and PyPy
* Flask HEAD, maintenance branch, and latest release
* each listed Flask extension
The builtin buildbot screens do not present this combination very
well. That's why we have a JSON API:
http://74.207.234.95:8010/json/help
I've experimented with this JSON API, but determined the data need to
be indexed in order to present the various views of the data that are
of interest to the community. Maybe we should have a hackathon.
yours,
Ron
> At my work before switching to Python/Django, we added functionalities and
> made them look like it was the old website. When we replaced PHP by Python
> it was a top-to-bottom switch. Maybe there are other strategies, what do you
> think ?
>
>
>>
>> On Wed, Oct 19, 2011 at 2:33 AM, Amirouche Boubekki
>> <amirouche.boubekki@gmail.com> wrote:
>> > 2011/10/17 Soj <sojin.v@gmail.com>
>> >>
>> >> http://invenio-software.org/wiki/Talk/WebFrameworks
>> >
>> > This article explains the pros and cons of different python web
>> > frameworks
>> > to replace the in-house python framework used by the fundation to build
>> > a
>> > library application used in several research center.
>> >
>> > The winner is Flask.
>> >
>> > It's interesting but I don't know how this can help in my situation
>> > where
>> > the legacy application is written in PHP.
>> >
>> > Interesting read, thanks for sharing.
>> >
>> > Amirouche aka abki
>> >
>> >
>
>
Re: [flask] Good read
- From:
- Amirouche Boubekki
- Date:
- 2011-10-26 @ 12:53
Thanks for all you feedback.
Amirouche
2011/10/19 Ron DuPlain <ron.duplain@gmail.com>
> Executive summary: The boss raises valid points in software risk, each
> of which can mitigated by a subtle shift in process where open source
> packages are not treated as black boxes. Have the team conduct code
> reviews, both of internal code and relevant open source projects, and
> give developers some time to read the code they are using. It's not a
> question of Flask vs Django or Python vs PHP, but whether the team is
> able to make progress on new developments while maintaining an
> existing code base with the resources they have. No software is
> bug-free, in part because a bug does not exist without context.
> Either give your team the process they need, or get a support contract
> to keep your risk levels safe.
>
> For further reading: see Cathedral and the Bazaar (1997-2001), by Eric
> S. Raymond, freely available online. Raymond draws upon the
> literature and from his own experience to discuss the very nature of
> open versus closed software development processes, for production code
> and not just open source.
>
> I respond to specific points below. See also the extended post from
> Adam Patterson.
>
> On Wed, Oct 19, 2011 at 3:30 AM, Amirouche Boubekki
> <amirouche.boubekki@gmail.com> wrote:
> > There are several issues.
> >
> > The first question the boss asks is: isn't Flask a dead end ? The project
> is
> > written and maintained by a student not a business. Armin can stop
> working
> > on the project and Flask story could end.
>
> The boss clearly hasn't met Armin.
>
> Also, the Flask core team is larger than just Armin; perhaps we should
> be more clear about that. Finally, the Pocoo Team has major
> contributors to Flask maintenance who are not listed as committers on
> the project. In fact, the Pocoo Team is likely a larger operation
> than that of the boss'.
>
> This point is key: a project backed by a business does not give you a
> support contract any more than an engineering degree makes for more
> maintainable code.
>
>
> > Then comes the arguments about Flask vs Django. The boss see Django as
> the
> > mainstream solution so it's difficult to explain where Flask is better.
> > Arguing that Flask is better because it's better code, solve problems in
> a
> > better way using proven solutions like SQLAlchemy don't talk to him. He
> > wants examples of PHP->Flask experience or at least projects that use
> Flask
> > for their business and if possible with same complexity as the ones he
> wants
> > to re-build.
>
> Flask is not Django, and last I checked, the Flask project has no
> intention to replace Django.
>
> For experiences in using Flask, reach out to the list or visit
> http://flask.pocoo.org/community/poweredby/ and pick up the phone.
>
>
> > In the link it's a Python->Python switch so their is a bunch of code that
> > can be re-used, but in the case of PHP->Python only phpserialize can help
> in
> > some places.
>
> In my opinion, this is a systemic issue in too much reliance on a
> framework. I personally avoid monolithic projects in favor of a
> collection of focused, semantically versioned (semver.org) packages.
> At some point, you can put your business logic into a
> framework-independent library. That's up to your engineering team.
>
>
> > Another reason not to use Flask is the lake of third party applications
> > (third party extensions in Flask nomenclature). At my current job we
> heavily
> > rely on third party code. This is a choice, it holds even if most of them
> > were tweaked or re-written (which makes me think that it might not have
> been
> > a good idea all the time.). In current Flask ecosystem what extensions
> are
> > trying to bridge the gap between Flask as microframework and Django. But
> > there is not goodie extensions like django-messages, django-favorites or
> > anything that keeps you from writing more code and actually implement
> > functionalities of the website and not the framework. Flask being ORM
> > agnostic makes it harder to build extensions.
>
> Biggest feature to me: Flask has listed and approved extensions.
>
> Flask has a clear extension pattern which is very Pythonic (defined
> via `import this`), approved/reviewed extensions (!!), a
> well-documented extension review process, and a dedicated buildbot
> running tests on every commit to the entire stack, the Flask core and
> each listed extension.
>
> Here is the buildbot, but its reporting facilities are currently not
> ready for public use.
> http://74.207.234.95:8010/builders
>
> The fault for this buildbot not yet being public is entirely mine.
> The user experience for the current reporting screens is entirely
> lacking. The buildbot has a combinatorial matrix of:
>
> * Python 2.5, 2.6, 2.7 and PyPy
> * Flask HEAD, maintenance branch, and latest release
> * each listed Flask extension
>
> The builtin buildbot screens do not present this combination very
> well. That's why we have a JSON API:
> http://74.207.234.95:8010/json/help
>
> I've experimented with this JSON API, but determined the data need to
> be indexed in order to present the various views of the data that are
> of interest to the community. Maybe we should have a hackathon.
>
> yours,
>
> Ron
>
>
> > At my work before switching to Python/Django, we added functionalities
> and
> > made them look like it was the old website. When we replaced PHP by
> Python
> > it was a top-to-bottom switch. Maybe there are other strategies, what do
> you
> > think ?
> >
> >
> >>
> >> On Wed, Oct 19, 2011 at 2:33 AM, Amirouche Boubekki
> >> <amirouche.boubekki@gmail.com> wrote:
> >> > 2011/10/17 Soj <sojin.v@gmail.com>
> >> >>
> >> >> http://invenio-software.org/wiki/Talk/WebFrameworks
> >> >
> >> > This article explains the pros and cons of different python web
> >> > frameworks
> >> > to replace the in-house python framework used by the fundation to
> build
> >> > a
> >> > library application used in several research center.
> >> >
> >> > The winner is Flask.
> >> >
> >> > It's interesting but I don't know how this can help in my situation
> >> > where
> >> > the legacy application is written in PHP.
> >> >
> >> > Interesting read, thanks for sharing.
> >> >
> >> > Amirouche aka abki
> >> >
> >> >
> >
> >
>
Re: [flask] Good read
- From:
- Adam Patterson
- Date:
- 2011-10-19 @ 08:13
On Wed, Oct 19, 2011 at 2:30 PM, Amirouche Boubekki
<amirouche.boubekki@gmail.com> wrote:
> The first question the boss asks is: isn't Flask a dead end ? The project is
> written and maintained by a student not a business. Armin can stop working
> on the project and Flask story could end.
You said you rely on a lot of 3rd party code already. I bet that code
is not nearly as clean, documented and supported as flask currently
is. Flask is small. You can wrap your head around the entire framework
easily and just own it. If Armin stops working on the project people
will continue to work on it. Lot's of people use it.
> Then comes the arguments about Flask vs Django. The boss see Django as the
> mainstream solution so it's difficult to explain where Flask is better.
Only you can know that for your own project. I have large projects.
One with Django and one with Flask. I wouldn't switch either of them
to the other framework. They both do the job they are suited to do.
Use the correct tool for the job
> Arguing that Flask is better because it's better code, solve problems in a
> better way using proven solutions like SQLAlchemy don't talk to him. He
> wants examples of PHP->Flask experience or at least projects that use Flask
> for their business and if possible with same complexity as the ones he wants
> to re-build.
I can't help you here.
> In the link it's a Python->Python switch so their is a bunch of code that
> can be re-used, but in the case of PHP->Python only phpserialize can help in
> some places.
This is not a Flask issue. This is a "moving to a new language" issue.
> But there is not goodie extensions like django-messages, django-favorites or
> anything that keeps you from writing more code and actually implement
> functionalities of the website and not the framework. Flask being ORM
> agnostic makes it harder to build extensions.
I looked at both of these app. Neither are complex (favorites is only
~100 loc with comments). They would take a very small amount of time
to port to Flask. It's already python. But you are correct, there are
not as many apps/extensions for flask currently. That's just something
you will have to take into consideration.
It really depends on the site you are creating. I personally use
Django for content heavy sites with contributors and Flask for
applications.
>>
>> On Wed, Oct 19, 2011 at 2:33 AM, Amirouche Boubekki
>> <amirouche.boubekki@gmail.com> wrote:
>> > 2011/10/17 Soj <sojin.v@gmail.com>
>> >>
>> >> http://invenio-software.org/wiki/Talk/WebFrameworks
>> >
>> > This article explains the pros and cons of different python web
>> > frameworks
>> > to replace the in-house python framework used by the fundation to build
>> > a
>> > library application used in several research center.
>> >
>> > The winner is Flask.
>> >
>> > It's interesting but I don't know how this can help in my situation
>> > where
>> > the legacy application is written in PHP.
>> >
>> > Interesting read, thanks for sharing.
>> >
>> > Amirouche aka abki
>> >
>> >
>
>
Re: [flask] Good read
- From:
- Jesaja Everling
- Date:
- 2011-10-19 @ 08:23
+1 for all what Adam said!
I just wanted to add one point about SQLAlchemy.
> Arguing that Flask is better because it's better code, solve problems in
a better way using proven solutions like SQLAlchemy don't talk to him.
If you already have legacy data, it's most certainly much easier to
use the existing tables with SQLAlchemy, than to get your data to work
with the Django ORM somehow.
So that may be one argument to convince the boss that Flask is much
better suited (of course it's possible to use SQLAlchemy with Django,
but you will lose most extensions and the admin that way).
Django is great if you are doing everything the way it's intended to
be done with Django. If you do things differently, and this starts
with things like a different User model, than you will appreciate the
flexibility that Flask offers.
Best Regards,
Jesaja Everling
On Wed, Oct 19, 2011 at 10:13 AM, Adam Patterson <fakeempire@gmail.com> wrote:
> On Wed, Oct 19, 2011 at 2:30 PM, Amirouche Boubekki
> <amirouche.boubekki@gmail.com> wrote:
>> The first question the boss asks is: isn't Flask a dead end ? The project is
>> written and maintained by a student not a business. Armin can stop working
>> on the project and Flask story could end.
>
> You said you rely on a lot of 3rd party code already. I bet that code
> is not nearly as clean, documented and supported as flask currently
> is. Flask is small. You can wrap your head around the entire framework
> easily and just own it. If Armin stops working on the project people
> will continue to work on it. Lot's of people use it.
>
>> Then comes the arguments about Flask vs Django. The boss see Django as the
>> mainstream solution so it's difficult to explain where Flask is better.
>
> Only you can know that for your own project. I have large projects.
> One with Django and one with Flask. I wouldn't switch either of them
> to the other framework. They both do the job they are suited to do.
> Use the correct tool for the job
>
>> Arguing that Flask is better because it's better code, solve problems in a
>> better way using proven solutions like SQLAlchemy don't talk to him. He
>> wants examples of PHP->Flask experience or at least projects that use Flask
>> for their business and if possible with same complexity as the ones he wants
>> to re-build.
>
> I can't help you here.
>
>> In the link it's a Python->Python switch so their is a bunch of code that
>> can be re-used, but in the case of PHP->Python only phpserialize can help in
>> some places.
>
> This is not a Flask issue. This is a "moving to a new language" issue.
>
>> But there is not goodie extensions like django-messages, django-favorites or
>> anything that keeps you from writing more code and actually implement
>> functionalities of the website and not the framework. Flask being ORM
>> agnostic makes it harder to build extensions.
>
> I looked at both of these app. Neither are complex (favorites is only
> ~100 loc with comments). They would take a very small amount of time
> to port to Flask. It's already python. But you are correct, there are
> not as many apps/extensions for flask currently. That's just something
> you will have to take into consideration.
>
> It really depends on the site you are creating. I personally use
> Django for content heavy sites with contributors and Flask for
> applications.
>
>>>
>>> On Wed, Oct 19, 2011 at 2:33 AM, Amirouche Boubekki
>>> <amirouche.boubekki@gmail.com> wrote:
>>> > 2011/10/17 Soj <sojin.v@gmail.com>
>>> >>
>>> >> http://invenio-software.org/wiki/Talk/WebFrameworks
>>> >
>>> > This article explains the pros and cons of different python web
>>> > frameworks
>>> > to replace the in-house python framework used by the fundation to build
>>> > a
>>> > library application used in several research center.
>>> >
>>> > The winner is Flask.
>>> >
>>> > It's interesting but I don't know how this can help in my situation
>>> > where
>>> > the legacy application is written in PHP.
>>> >
>>> > Interesting read, thanks for sharing.
>>> >
>>> > Amirouche aka abki
>>> >
>>> >
>>
>>
>