http://bottlepy.org/docs/dev/tutorial.html#quickstart-hello-world maybe this would be a nice framework to use (it is extremely minimalistic) for implementing the end-points.
other points to discuss:
- The answers we'll give from the API calls should be in json, right?
- do we use a DB, finally, or not? So we store the entries inside a DB (how does this work for long text entries?), then have the possibility to "export to files"? Or we use the file system as a sort of DB, with a file per entry, then recreate at will a more compact version? I am somehow not a big fan of it, as I like having files...
- the question, db or not .. I think we can use a db and don't have to think about text fields that much. I don't know If there are any limits for the text fields. DBs should have "fulltext" fields that can get pretty big.
If we don't want to use a db, we can stay with the current system. One file per notebook, then we can use almost all the current code, we can just refactor it a bit to get a better separation. The "export" would just be a copy or you can even go into the filesystem directory as we do at the current point.
One file per entry would mean, we can move away from the stiff notebooks more easily. An export would mean, read all needed notes and write them sequential, right?
Flat files as we use them now allways have the benefit that you can throw away all the code and just open the files again without loosing (any|much) information.
In the stackoverflow question they talk about real database servers that lead to a lot of overhead. I think we should compare flat files to sqlite .. that's a different story.
the longer I think about it the more I doubt that we need a real RESTful API. That would only be needed when we really want to have a server/client model. If not, we just need to put the storage code into a library with a clear API or architecture, but we don't need to build two separate applications
looks like an issue with
qtpy
I'll look further into the issue with version
1.0b1. It looks like they pulled some code from upstream that messed up the check for the QT-library
when I import qtpy, there's no assert error
so it only triggers when called from qtawesome?
do we set the environment variable? I remember that you had problems with it, when both PySide and PyQt were installed ..
and they check for another string:
'PySide' != 'pyside'
I'll merge that, thanks for investigating
at least to see what is their opinion on that
I just learned that I can just use
<C-I> in any input area to edit the text in an external editor. It took some time but I got it working with nvim in a terminal
set editor='termite -e "nvim +<line> +\"sil! call cursor(0, <column>)\" <file>"'
Although dropping python 3 support is not, definitely not, what should be done
I'll start adding type hints in my scripts, soon .. It really helps with the readability if you always know what type you have to expect
(yes, there are type hints as comments in python 2, but I think the syntax is very clean in python 3)
your comment to go for a walk while it's building was meant quite literal, I guess
while reading the neovim-newsletter I've seen that it's possible to embed this nodejs-component to another app. Would be nice to have as an editor