Python 3.3 and pyvenv, a (hackish) solution

EDIT: it seems to be a bug in debian experimental, if you install python3.3 from the upstream tarball, you will not find this issue, the resolution of this bug is tracked in both Debian BTS and python BTS .

EDIT2: I could confirm that in debian unstable as of July 2013 is fixed. In this case you will be done with:

$ pyvenv-3.3 ~/.pyvenv-3.3
$ . ~/.pyvenv-3.3/bin/activate
(.pyvenv-3.3)$ curl -O http://python-distribute.org/distribute_setup.py
(.pyvenv-3.3)$ python distribute_setup.py
(.pyvenv-3.3)$ easy_install pip

In the previous blog post I got stuck in properly creating a virtualenv in python 3.3, now I came with this hacky script, which naively wraps pyvenv-3.3 and create a couple of missing links which makes everything works fine. In fact I saw that virtualenvs created with virtualenv .27 tools makes links from directories in <virtualenv>/local/{bin,lib,include} to <virtualenv>, those links are missing in venv created by pyvenv-3.3.

So here it is the hackish wrapper script:

#!/bin/sh

VENV_PATH="$1"
PROGRAM="$(basename $0)"

if [ -z "${VENV_PATH}" ]; then
    echo "Usage:" 1>&2
    echo "${PROGRAM} VENV_PATH" 1>&2
    exit 1
fi

shift 1

echo pyvenv-3.3 "${VENV_PATH}" "${@}"
pyvenv-3.3 "${VENV_PATH}" "${@}"

mkdir -p "${VENV_PATH}/local"

for dir in lib bin include ; do
    ln -vs ../${dir} "${VENV_PATH}/local/${dir}"
done

Save this script somewhere in your PATH (e.g. /usr/local/bin/mk_pyvenv or maybe ~/bin/mk_pyvenv) and then issue:

$ mk_pyvenv ~/.pyvenv-3.3
$ . ~/.pyvenv-3.3/bin/activate
(.pyvenv-3.3)$ curl -O http://python-distribute.org/distribute_setup.py
(.pyvenv-3.3)$ python distribute_setup.py
(.pyvenv-3.3)$ easy_install pip

And now you finally have a working virtualenv with python-3.3 VENV!

python 3.3 and virtualenv

Tech

As in pep-0405 Python 3 new virtualenv specs are now implemented in Python 3.3.

Install python3.3 and venv it 

 

Python 3.3 has those bleeding edge venvs, lets try them and bleed!

#!/bin/sh
# please add the source if needed
# it could need a package from experimental

set -e # exit in case of errors 

if grep -vqs "experimental main" ; then
    echo "deb http://ftp.de.debian.org/debian/ experimental main" | \
    sudo tee -a /etc/apt/sources.list > /dev/null
fi

sudo apt-get install python3.3
pyvenv-3.3 .pyvenv-3.3
. .pyvenv-3.3/bin/activate 

Install pyglet 

# pip install pyglet # if lucky and in the future
 
# maybe check for something >= 1.2 on http://www.pyglet.org/download.html#unstable
wget http://pyglet.googlecode.com/files/pyglet-1.2alpha1.tar.gz
cd pyglet-1.2alpha11
python setup.py install

  Install pip

curl -O http://python-distribute.org/distribute_setup.py
python distribute_setup.py

I dreamed now for

easy_install pip

but I had to do that uglyness below, I'm missing a prefix probably (I hope!)

mv .pyvenv-3.3/local/lib/python3.3/dist-packages/ .pyvenv-3.3/lib/
easy_install-3.3 pip

Is there something wrong here?

Python: "source" a shell script and read variables

It comes handy to "source" a shell script and read variables from there in python, maybe to share configuration between different scripts.

Here is my* take:

from subprocess import Popen, PIPE
from os import environ

def source(script, update=True, clean=True):
    """
    Source variables from a shell script
    import them in the environment (if update==True)
    and report only the script variables (if clean==True)
    """

    global environ
    if clean:
        environ_back = dict(environ)
        environ.clear()

    pipe = Popen(". %s; env" % script, stdout=PIPE, shell=True)
    data = pipe.communicate()[0]

    env = dict((line.split("=", 1) for line in data.splitlines()))

    if clean:
        # remove unwanted minimal vars
        env.pop('LINES', None)
        env.pop('COLUMNS', None)
        environ = dict(environ_back)

    if update:
        environ.update(env)

    return env

Also available as a github gist.

* Heavily inspired from this pythonwise blog post

VDE Virtual Networking

Una delle cose veramente utili e divertenti della virtualizzazione è la possibilità di fare facilmente dei test dove altrimenti sarebbe scomodo, lento o troppo costoso farli su delle macchine vere.

Già da tempo esistono software come QEmu o VirtualBox che virtualizzano un intero computer, compreso bus PCI con schede audio, video e di rete; da meno tempo invece si trovano virtualizzazioni meno "spinte" come il progetto Virtual Square, che si propone come aggregatore di progetti di virtualizzazioni parziali, di singoli componenti o funzionalità.

Una virtualizzazione meno spinta ha la possibilità di essere più veloce o meglio integrata con software e sistemi non virtualizzati, con meno layer; permette anche di usarne un singolo componente in altri contesti.

Questa brevissimo accenno a Virtual Square serve solo per poter introdurre un loro progetto: VDE, reti virtuali. Invece che macchine intere, "semplici" componenti per interconnettere macchine reali e virtuali con nodi e cavi virtuali.

Gli switch di VDE sono switch a tutti gli effetti, con console di management via socket, e supportano tagged VLAN e cavi virtuali per interconnetterli tra loro, verso switch virtuali su macchine remote (tramite tunnel cifrati) e verso interfacce TUN sulla macchina reale.

Vediamo per esempio come simulare un server DHCP che serva due sottoreti differenti con alcune macchine virtuali, degli switch virtuali e un router virtuale (dhcp relay).

Creo una nuova interfaccia tap con permessi per il mio utente:

$ sudo tunctl -u marco
Set 'tap0' persistent and owned by uid 1000 

Lancio tre switch virtuali, di cui il primo lo aggancio alla tap0 appena creata:

$ vde_switch --unix /var/tmp/vde1.s --mgmt /var/tmp/vde1.m --tap tap0 --daemon 

$ vde_switch --unix /var/tmp/vde2.s --mgmt /var/tmp/vde2.m --daemon 

$ vde_switch --unix /var/tmp/vde3.s --mgmt /var/tmp/vde3.m --daemon

Lancio una macchina virtuale KVM (qemu con supporto hardware per la virtualizzazione) con due schede di rete collegate agli switch (fondamentale specificare i mac address)

$ kvm -hda hda-qemu.qcow -m 512 -net nic,macaddr=00:11:22:33:44:55,vlan=0 -net nic,macaddr=00:11:22:33:44:56,vlan=1 -net vde,sock=/var/tmp/vde1.s,vlan=0 -net vde,sock=/var/tmp/vde2.s,vlan=1

Lancio un paio di macchine virtuali con una debian live da cdrom, ognuna collegata ad un diverso switch:

$ kvm -cdrom debian-live-squeeze-i386-standard.iso -net vde,sock=/var/tmp/vde1.s -net nic,macaddr=00:11:22:33:44:10

$ kvm -cdrom debian-live-squeeze-i386-standard.iso -net vde,sock=/var/tmp/vde3.s -net nic,macaddr=00:11:22:33:44:11

Collego tra loro lo switch 2 e 3 (per fare test con le vlan per esempio):

$ dpipe vde_plug /var/tmp/vde2.s = vde_plug /var/tmp/vde3.s &

Mi collego all'interfaccia di management dello switch 2 e doò alcuni comandi:

$ unixterm /var/tmp/vde2.m

VDE switch V.2.2.3
(C) Virtual Square Team (coord. R. Davoli) 2005,2006,2007 - GPLv2

vde$ port/allprint
0000 DATA END WITH '.'
Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
 Current User: marco Access Control: (User: NONE - Group: NONE)
 IN:  pkts          2          bytes                  168
 OUT: pkts          0          bytes                    0
  -- endpoint ID 0003 module unix prog   : QEMU user=marco PID=10452  SOCK=/var/tmp/vde2.s/.10452-00000
Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
 Current User: marco Access Control: (User: NONE - Group: NONE)
 IN:  pkts          0          bytes                    0
 OUT: pkts          2          bytes                  168
  -- endpoint ID 0008 module unix prog   : vde_plug: user=marco PID=10461  SOCK=/var/tmp/vde2.s/.10461-00000
.
1000 Success

vde$ help
0000 DATA END WITH '.'
COMMAND PATH       SYNTAX          HELP
------------       --------------  ------------
ds                 ============    DATA SOCKET MENU
ds/showinfo                        show ds info
help               [arg]           Help (limited to arg when specified)
... omesso ...
vde$ vlan/create 42
1000 Success

vde$ port/setvlan 1 42
1000 Success

vde$ port/setvlan 2 42
1000 Success

Collego uno switch (stupido) layer 3 allo switch 1 e 3:

$ vde_l3 -v /var/tmp/vde1.s:10.0.8.1/255.255.255.0 -v /var/tmp/vde3.s:10.0.1.1/255.255.255.0 -M /var/tmp/vde_l3.m

Senza fare un tutorial preciso e lungo sul dhcp diciamo che l'host virtuale con le due schede di rete necessita di un server dhcp (collegato eventualmente al dns) configurato per servire due subnet diverse pur rimanendo esso su una sola delle due subnet (metti due subnet /24, il dhcp avrà la scheda di rete configurata su una delle due, non un network /16).

Putroppo il router virtuale (switch "layer 3") dovremo eliminarlo perché per ora non supporta il dhcp-relay e dunque deve essere sostituito con una macchina virtuale con due schede di rete che abbia installato il pacchetto dhcp-relay e forwarding tra le interfacce abilitato.


Lascio la configurazione DHCP e DNS in /dev/null, magari la aggiungerò qui sotto più avanti.

L'Arte della Programmazione su Unix

Tratte da "The Art of Unix Programming" (traduzione libera):

Regola 0: Keep it simple, stupid! (KISS)

1. Regola di Modularità: Scrivi parti semplici connesse da interfacce pulite.
2. Regola di Chiarezza: La chiarezza è meglio della ingegnosità.
3. Regola di Componibilità: Progetta i programmi per essere connessi ad altri programmi.
4. Regola di Separazione: Separa le specifiche dalle meccaniche, le interfacce dai motori.
5. Regola di Semplicità: Progetta verso la semplicità e aggiungi complessità solo dove necessario.
6. Regola di Parsimonia: Scrivi un programma grosso solo quando è chiaro con evidenza che nient'altro può farcela.
7. Regola di Trasparenza: Progetta per la visibilità per rendere il dubug e l'ispezione più semplice.
8. Regola di Robustezza:: La Robustezza è figlia della traparenza e della semplicità.
9. Regola di Incapsulamento: Raggruppa la conoscenza nei dati in modo che la logica possa essere stupida e robusta.
10. Regola di Minor Sorpresa: Nel progettare le interfacce, fai sempre la cosa meno sorprendente.
11. Regola del Silenzio: Quanto un programma non ha nulla da dire, non dovrebbe dire nulla.
12. Regola del Rimedio: Quando si deve crashare, meglio farlo rumorosamente e il prima possibile.
13. Regola Economica: Il tempo del programmatore è costoso, preferiscigli il tempo macchina.
14. Regola di Generazione: Evita le modifiche manuali; scrivi programmi che scrivano programmi quando possibile.
15. Regola di Ottimizzazione: Crea un prototipo prima di raffinare. Fallo funzionare prima di ottimizzare.
16. Regola della Diversità: Diffida di tutte le dichiarazioni dell'esistenza di "un unico vero modo".
17. Regola di Estensibilità: Progetta per il futuro, perché arriverà prima di quanto ti possa immaginare.