Sunday, August 30, 2015

python and sqlite

Links:
A previous post discussed the huge (250MB) installation of PostgreSQL for something as robust as a LAMP. However, suppose I just need a small database to keep track of business cards or some such?

SQLite CLI

Unlike PostgreSQL, SQLite has no server: everything is contained in a local "db" file you create. You can easily back it up by just backing up the file. To "connect" to the database, just go in the directory with that database and find the database, let's say it's "sample.db". Then...
$ sqlite3 sample.db
... and just do your business. Once complete, it's ".exit". Much easier for this kind of thing is a simple GUI, like sqliteman (Qt based).

Python access - APSW

But in our Python app, we'll want to access this database directly from the app, so we need a class of Python commands. If we want we can use SQLite commands and just import SQLite into the our code...
#!/usr/bin/python
import os,sys,time
import sqlite3
... and use SQL language, intermixed with Python.

But if we want a wrapper with a set of Python classes, the easiest Arch module to install is APSW (# pacman -S apsw) which is technically a wrapper, not a module, but still provides a class for interacting with SQLite databases.

Once we have that, we can start our code with, say...
#!/usr/bin/python
import os,sys,time
import apsw
...and and go on from there. However, I don't need any SQLite wrappers for the level of programming that I do --- I just write the database related commands in SQL. It's not that hard.

Python application

Remember that standalone Python programs are relatively simple to accomplish in Linux, but it depends on whether one compiles against a Python release and set of libs, or attempts to include these all in the package. Since most of what you run on your machine are scripts, like Bash scripts, the only thing you need to worry about among Python releases is what modules are natively available. The way to get to this is to first determine the highest version of Python on your system, and then see if you have modules you need to run your scripts.

Example

Suppose I'm building a script that I want to create a GTK window for (or Qt, but lets use GTK in this example), and so I've got gtk3 and pygtk installed. I'm going to check the version of Python and then list its modules and see if it has gtk and pygtk modules.
$ python --version
Python 3.4.3
$ python3
Python 3.4.3 (default, Mar 25 2015, 17:13:50)
[GCC 4.9.2 20150304 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help('modules')
[all modules are listed]
>>> exit()
I check the modules list and note gtk and pygtk are in the Python 2 modules list, but are not in the Python 3 modules list. Some Googling shows that Python 3 has a compatibility module, pygtkcompat, which emulates pygtk. All I need to do then is import pygtkcompat and configure it. Following that, I treat my code as gtk and pygtk existed. For example, the script might begin...
#! /usr/bin/python3

import os, sys, time
import pygtkcompat

# enable "gobject" and "glib" modules
pygtkcompat.enable()
pygtkcompat.enable_gtk(version='3.0') #matches shebang
import gtk
import glib
...and then whatever code came subsequently. Normal GTK "WINDOW" commands are available for example.

managers: system, session, window, volume, preference (and some use a display)

Links: using systemd as a session manager ::
I miss the SysV days when system, session, window (eg. "compositing"), volume, preference, and display managers were all cleanly defined. In fact, we never even needed the preference manager, gconf, because configurations were done with simple text files for each app. I'm just a regular user, and it takes me a lot of work these days to keep these managers separate or find their configuration files. They also seem to intertwine on occasion, requiring detangling time, as well.

Display Manager Disclaimer

Logins, startx, and shutdown are the only terminal commands needed in a normal session. Display Managers are only needed to make these more aesthetic. Accordingly, I haven't used a display manager in ten years. Why have an aesthetic login if it costs memory and potential fails? Second, not using it removes one variable from the kludge of 6 managers just listed above. Display Managers inadvertently obscure any start-up fails by keeping text log access out of sight. That's a problem during an install. In fact, during installs, I obtain a solid Runlevel 2 before downloading any X elements.

Session manager sussed-out

I attempted to tweak Evince's default zoom level the other day without gvfs (gnome's volume manager) installed. Sadly, Evince does not use old-skool config files; users have to set "schema keys", which are probably xml files. At any rate, one starts at the top, the correct schema, and then one modifies its key: find the schema, then its possible keys. To shorten the codeblock below, here were the two Evince-related schemas using the list-schema flag :
$ gsettings list-schemas
org.gnome.Evince.Default
org.gnome.Evince
And then the keys for those schemas.
$ gsettings list-keys org.gnome.Evince
document-directory
auto-reload
override-restrictions
page-cache-size
allow-links-change-zoom
pictures-directory
show-caret-navigation-message

$ gsettings list-keys org.gnome.Evince.Default
window-ratio
continuous
fullscreen
show-toolbar
show-sidebar
dual-page-odd-left
inverted-colors
zoom
sidebar-page
sidebar-size
dual-page
sizing-mode
It appears the "zoom" key is the one to set, which is in schema Evince.Default.
$ gsettings set org.gnome.Evince.Default zoom 1.0
$ gsettings get org.gnome.Evince.Default zoom
1.0
We can see the zoom was set correctly (to 100%). Now let's run Evince:
$ evince
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Evince starts, but spawns the error above and only the default zoom factor, instead of the 100% zoom I entered.

Was gnome-session not running, sharing with systemd, or what? A simple setting can often means days of frustration in Linux. If I recall correctly, it's further the case, that gnome-session can only be started after dealing with PAM, like via gdm-password. It's unlikely any gnome sessions are running.
# ps -A |grep -i g
614 ? 00:00:00 gconfd-2
3602 pts/2 00:00:00 grep
31658 ? 00:00:00 gnome-pty-helpe
Now it's clear: no gnome-session is running. The gsetting commands were accepted. That is because, for the settings to be entered, only gconfd, gnome's preference manager, had to be running. However, there was no way to implement those preferences, because the session manager, gnome-session, was not running: an error message was generated. Meanwhile, Arch recommends against any gconf schemas, and notes they will soon be replaced with "dconf". Currently then, Evince is probably caught in the middle of these. We really have no way to configure Evince without getting a session manager going, which in turn probably requires the dreaded gvfs by the way.

Okular

In spite of the immense KDE libraries necessary for Okular, I have to look. I mean if I can just set preferences at this point, I'd be happy.




Saturday, August 15, 2015

[solved] first run of zotero back-up

I had a chance to recently attempt my first Zotero back-up and resoration. I have the stand-alone version, which I then link to a few browsers with browser plug-ins (see bottom of page). In other words, Zotero installs as a regular application, available on or offline. Zotero browser-plugins (typically XPI) install into the desired browser independent of whether Zotero is installed on one's system at all.

other bibliography/citation-related notes

BibTex tutorial :: exporting cite keys from Zotero :: helping cite keys match database


Overview

From what I could tell from Zotero's instructions, all I would need to do is backup my entire Zotero directory, and then put it in the new drive. Helpful, but experience showed it could be broken down more explicitly:
  1. Back-up the Zotero database directory (usually a few hundred MB; mine fits on a CD).
  2. Install a blank version of Zotero, on the new drive. Be sure Zotero is stable (open and close it a couple times).
  3. Add a browser connector, if you want or need one (optional).
  4. Take the backed-up data directory and overwrite the fresh install's data directory.
  5. Open Zotero and all backed-up citations should be there.
  6. Associated back-up issue: suppose one has a folder with several Ebooks or PDF's on some subject. Zotero can apparently store local HDD links to these documents, as well as metadata about the them. These links will also be in the Zotero database, just like web links, and using links uses less space in the database than the full documents would use. However, after backing up Zotero on a new install, you'll also need to duplicate the directory structure where these documents are kept. In this way, Zotero's links will point to the documents.

Back-up

Initially, I made a mistake. I backed-up the Zotero directory, burning it onto a DVD with other data. This directory and all files within it were suspiciously only about 10MB. Eventually I determined I had only backed-up the application directory. The data directory is what should be backed-up. But the data directory is not in plain sight within the directory structure. To find the data directory, I searched for one of its files, zotero.sqlite:
$ find -name zotero.sqlite
./.zotero/zotero/af5baci7.default/zotero/zotero.sqlite
This is the correct Zotero directory to back-up, the data directory. That is, ~.zotero/zotero/[hashnumber].default/zotero/*. This directory was a few hundred MB. As for the application directory, why back it up at all? Download and install the latest version of Zotero instead.

Restoring

First, install the Zotero app, either the old one or the latest version. If it's a new install it will create a new folder in your home directory: ~.zotero/zotero/[newhashnumber].default/zotero/. Open and close Zotero a couple times to be sure the install is clean. Then just take the old data directory (you backed-it up above) and overwrite the new data directory. Your new structure will be something like ~.zotero/zotero/[newhashnumber].default/zotero/[old backed-up data]. The next time I opened Zotero, my backed-up citations were there.

Connect to browsers (optional)

You can manually enter Zotero entries. Browser plug-ins make it easier for some online sources. But after a back-up, the connector between stand-alone Zotero and its browser plug-ins, may or may not be broken. Once the standalone is working and up-to-date, start Zotero and then go to the links for the connector that matches the browser you like. Here's a couple of them.

Chromium
Chromium Zotero Connector

Opera
Opera Zotero Connector