Split bottle.py in the repo

[tarekziade]

trafficstars

While I find the idea of release a single file is a nice release format, I think this should be only done at release timen so the source code is not in one single huge python file and is easier to read / hack.

[defnull]

I often thought about that but the single-source-file strategy has benefits, too: It avoids bloated and unreadable code and makes me thing twice before adding more features or applying unmatured patches.

[tarekziade]

I am not sure how a single file makes it easier to avoid bloated or unreadable code (I'd say the opposite). But maybe that's just me :)

[sgala]

I tend to agree with defnull. Additionally, the "build" will get more complex if there is a need to put together several fragments, and the difference between development and production "environments" will also make things more complex.

About the only problem I've seen with the current approach is that git gui blame is a bit slower than it might end up being with a more fragmented source base.

I think that in the future, as the server and template adapters multiply, they might end up outside of the main bottle. I can also imagine a future where "main" bottle is two files: one for the framework and another one for the SimpleTemplate stuff, plus adapters and/or useful middleware in a "contrib" area.

[defnull]

I think some kind of build-process and a split-out of pats of the bottle framework is inevitable by now. The multipart-parser for example (#80) is quite useful on its own and should stay in a separate repository. There are other parts of Bottle that are both useful and complex enough to justify a separate file or even repository. SimpleTemplate is one of them.

To keep bottle dependency-less at the same time, we need some kind of automated integration script to include the sources of external libraries into Bottle without pulling any redundant or useless stuff. That implies some kind of build-process to create a working bottle.py out of several other files. I don't like the idea to add this kind of complexity, but I think sooner or later it will be necessary.

Any ideas how to do this?

[shogsbro]

bottle.py already reflects a set of blocks:

1. bottle exceptions
2. Routing
3. WSGI interface & helpers
4. Server adapters
5. Templates
6. Stuff that would go in init.py

What I like about bottle.py is not that it is a single file, but that it has a clear purpose and does what it does well. That is what brought me here, from Pylons (which has too much bloat). The projects mentality is more important to me than the code organisation.

[defnull]

I started reordering and refactoring the bottle sources to prepare the split. The process involves some touch design decisions, so don't hold your breath :)

[cime]

Anything new on this one and on integrating multipart parser?

[allanderek]

I'd just like to add that I don't see any particular benefit to splitting the code up into separate files. Arguably the SimpleTemplate could be useful outside of bottle and hence could be useful to keep separate. But really, there are enough python templating engines if one wants templating without bottle.

[MTecknology]

FWIW- I think Bottle being a single file is neat, but not necessarily a technical merit. When I choose Bottle, it's because I'm looking for something that's light-weight, simple, easy, and gets out of my way. I enjoy the lack of dependencies; however, in >90% of my Bottle applications, I choose jinja2 over stpl. To me, jinja2 is just easier, with much wider support.

Personally, the first thing I would break out would be stpl. It seems more than large enough to be it's own project. Not only would this be a quick/easy line, it would make stpl available for other projects to make use of.

It lets me picture a world without mako_template() vs. jinja2_template() vs. template(), but rather just template([..], engine='?'), with a configuration value to specify the default.