is bottle still activly maintained?

[stephan schultchen]

is bottle still alive?

there are so many open issues in github, as well as open merge requests.

also the last release is from January 2017, and the last commit to master is 8 months old.

There are also deprecation warnings with the current plugin system, which should be fixed.

i really like bottle, but the project seems to get no love anymore.

i could offer some help, if needed.

but currently i am thinking about either forking bottle, or giving flask a try.

Kind Regards,

Stephan

[Daniel Watrous]

I started using bottle because flask wasn't being maintained and did not support Python 3. When the flask community picked back up on development and chose to support Python 3, I think the need for bottle was diminished.

I still like the simplicity of bottle and use it occasionally, but Flask is probably safer for larger, long lived projects.

[stephan schultchen]

hmm,

the main thing i am missing with flask is the plugin system, this is where bottle really shines.

i started yesterday to dig into the bottle code, and stripped everything that is related to python2 compatibility.

but i have to admit that i start to dislike the one file approach that bottle uses, and might try to split it up into different files, simply because a 4k+ lines file is not that easy to handle.

but it also would be nice if marcel hellkamp could make a note of what his plans with bottle are.

--
--
You are member of the "bottlepy" group at google groups.
See http://groups.google.de/group/bottlepy for mailing list options.
See http://bottlepy.org/ for news and documentation.

---
You received this message because you are subscribed to the Google Groups "bottlepy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bottlepy+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[peb aryan]

IMHO, one of the attractive point of bottle is this one file approach. 

it's less frightening for people who are new in the world of web framework in python. 

the practicality is comparable to using SimpleHTTPServer directly 

which make it easy to setup on small environments such as raspberry pi and alike. 

[Marcel Hellkamp]

Am 12.07.2018 um 16:34 schrieb stephan schultchen:
> i started yesterday to dig into the bottle code, and stripped
> everything that is related to python2 compatibility.

As long as the Python 2/3 dual-compatibility does not affect runtime
performance or prevent progress, I do not see a reason to drop it. The
only real downside is code-complexity within bottle, but that does not
affect the users of bottle. So, removing it would only have drawbacks
for the users an no real benefit.

> but i have to admit that i start to dislike the one file approach that
> bottle uses, and might try to split it up into different files, simply
> because a 4k+ lines file is not that easy to handle.

Bottle started as a one-file framework without dependencies mostly to
simplify deployment. It was designed for learning or weekend projects,
to quickly build a REST-APIs for some command line tool or sqlite
database, or to remote control a Raspberry PI or other embedded device.
These use cases are less prominent, but actually very common for bottle.
For these use cases, downloading a bottle.py file into your project
folder is way easier than doing it 'correctly' with virtualenv and pip.
Bottle still fully supports the 'correct' way, but having an easier
option to get started is a really nice feature.

But there is a second, even more important reason for the single-file
approach: Bottle is a micro-framework. Having everything in a single
file makes it easier for me an other contributors to keep it that way.
As soon as we'd split it up into multiple files, line count starts to be
less of an issue and large pull requests become hard to argue against.
Once you need pip to install bottle, adding an external dependency would
be just a small step. And then, adding even more dependencies would be
trivial. The spirit of bottle as a 'micro' framework would be lost.

Look at other 'micro' frameworks out there. Flask for example. If you
include its mandatory dependencies, you'd have an order of magnitude
more code to read if you would want to understand what is really going
on in your web application. The ~4k Lines in bottle can be read and
understand in a weekend. A stacktrace shows you exactly where the
problem is. If you do not understand the doc-string of a method, you can
open up bottle.py and just read the code. Try that with Flask.

Nice to know: Bottle is used in some security-sensitive environments and
its security was audited by at least two independent companies (that I
know of), and both hinted that bottle was chosen for exactly this
reason: It is small enough to be fully understood, and useful enough to
be worth the audit.

> but it also would be nice if marcel hellkamp could make a note of what
> his plans with bottle are.

Bottle is feature complete, mostly. Releasing 0.13 would be nice,
though, as it fixes a ton of issues and adds some nice little details,
but I made the same mistake I also made for 0.12: The change-set grew to
big, and I am not confided enough that there are no backwards
incompatible changes to release it. Bottle is very stable between
releases and I do not want to break this promise, but I do not have the
time to extensively test it myself, unfortunately.

What would help me a lot, is people migration their applications from
0.12 to the master branch, and tell me if that worked for them or not.
We also need to clean out some of the 'ideas' in 0.13 that are probably
not ready to become a stable API. The new Config feature for example.
Nice to have, but may as well be a plugin. I'm not sure.