FreeBSD und Ipython3 treibt mich zur Verzweiflung

morpheus

Well-Known Member
Hallo,

ich wollte auf meinem Rechner unter FreeBSD 9.1 eine Entwicklungsumgebung für Python 3.2 einrichten, ganz simpel bestehend aus Vim, Python 3.2 und Ipython. Eientlich nichts Spektakuläres. Doch leider treibt mich dieses Unterfangen so langsam in den Wahnsinn.

Python 3.2 aus den Ports zu installieren war kein Problem, aber leider scheinen sämtliche Ports nicht für 3.2 ausgelegt zu sein. Dem Vim konnte ich durch Editieren der Makefile ja noch beibringen, mit Python3-Support kompiliert zu werden, aber spätestens bei Ipython stoße ich an meine Grenzen. Der Port ist nicht für Python 3 konzipiert und wenn man die Python Version in etc/make.conf auf 3.2 setzt, erhält man sofort eine Fehlermeldung. Aber selbst wenn man den Port für Python 2.7 kompiliert, hat man keine QT-Konsole, sondern lediglich Ipython im Terminal.

Also dachte ich mir, OK, ziehst du dir halt den Quellcode direkt vom Server und installierst die Sachen manuell. Geht aber leider auch nicht, weil dafür wieder Tools wie easy_instal oder pip benötigt werden, die aber aus den Ports auch nicht bauen, wenn Python 3.2 als Standard angegeben ist. Somit stehe ich also wieder vor demselben Problem.

Hat jemand eine Lösung für dieses Problem, oder bin ich der Einzige, der Ipython für Python 3 unter FreeBSD benutzen möchte? Bei Ubuntu habe ich spezielle Pakete für Ipython3 und Ipython3-qtconsole gefunden, aber eigentlich möchte ich nur ungern den Schwenk auf Ubuntu vollziehen, weil mich bei Linux halt viele andere Dinge nerven. Trotzdem bin ich jetzt hier an einem Punkt angelangt, wo ich so nicht mehr weiter komme.

Hat jemand einen Tip für mich?

Gruß, Morpheus
 
Mehrere Zweige von Python werden von den Ports nicht wirklich unterstützt. Das Hauptproblem sind, wie schon erkannt, die ganzen Module. Es gibt da mehrere denkbare Ansätze. Aber sie brechen alle mit bestimmten Annahmen von denen das Binärpaketmanagement abhängt.
 
Mehrere Zweige von Python werden von den Ports nicht wirklich unterstützt. Das Hauptproblem sind, wie schon erkannt, die ganzen Module. Es gibt da mehrere denkbare Ansätze. Aber sie brechen alle mit bestimmten Annahmen von denen das Binärpaketmanagement abhängt.

Schade, also bin ich im Grunde gezwungen, für sowas doch Linux oder gleich Windows zu verwenden, wenn das Ganze nicht in elendes Gefrickel ausarten soll.

Schade, ich hatte eigentlich gehofft, dass es irgendeinen praktikablen Lösungsansatz gibt. Das sind dann immer so die Punkte, an denen ich mich frage, ob FreeBSD überhaupt für mich das passende Desktopbetriebssystem ist. Auf dem Server bin ich absolut überzeugt davon, aber dort sind es in der Regel auch nur wenige Aufgaben, die der Server übernehmen muss. Auf dem Desktop sieht das leider etwas anders aus und ich bin in der Vergangenheit schon häufiger über ähnliche Probleme gestolpert.
 
Ja, wie gesagt, das ist den Ports zu "verdanken". Die sind halt einfach stark eingestaubt und eingeschränkt.

Darum arbeitet man ja nach und nach ein einem Ersatz/Erweiterung und dann sollte das eigentlich dem Linux-Paketsystemen in nichts nachstehen (python2-, python3- Präfixe, etc.). Aber das dauert halt noch.
 
Das stimmt. Früher habe ich die Ports immer als sehr flexibel empfunden, aber mittlerweile merke ich doch zunehmend auch die Einschränkungen, die das Portsystem mit sich bringt. Mal ganz abgesehen davon, dass das Bauen aus den Ports doch immer einige Zeit in Anspruch nimmt.

pkgng ist da ja wohl ein guter Ansatz, aber es muss dann halt auch die entsprechenden Pakete geben, sonst nützt das Ganze nicht viel. Aber momentan hilft da wohl nur Warten und zwischenzeitlich dafür ein anderes System benutzen. Obwohl mich das echt ärgert, weil ich FreeBSD nach wie vor klasse finde und es eigentlich mein Lieblingssystem ist :-(
 
Ohne Garantie, aber zumindet einen ernsthaften Versuch wert:
/usr/ports/devel/py-virtualenv


Muss ja nich gleich poettering sein.
 
Danke, ich werde es testen. Aber ich fürchte, dass das auch nicht funktionieren wird, da freshports.org sagt, dass der Port Python 2.7 benötigt. Aber einen Versuch ist es wert.
 
Die virtuelle Umgebung mit virtualenv einzurichten, war kein Problem. Ebenso Ipython mit pip zu installieren. Allerdings beschwert sich Ipython nun, es könne keine History anlegen, da es dafür eine Sqlite-Datenbank benötigt.

pip install pysqlite funktioniert aber nicht, da wirft er mir eine Fehlermeldung aus:

Code:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 98: invalid continuation byte

Und richtig Spaß macht Ipython erst mit der QT-Konsole. Ich wollte pyside benutzen, leider scheitert es aber schon daran, dass der Port wohl nicht aktuell ist und eine Distfile herunterladen möchte, die es nicht mehr gibt.Ich könnte es natürlich noch mit py-qt versuchen, aber das ist nicht wirklich frei, von daher wäre mir pyside sympathischer. Und wer weiß, selbst wenn es gelänge, pyside zu installieren, welche Probleme würden mich dann wieder in Verbindung mit Python3 erwarten?

Wenn ich jetzt bedenke, dass ich Stunden erfolglos damit verbracht habe, sowas simples wie eine minimalistische "Entwicklungsumgebung" aufzusetzen... ;'(
 
Aus ähnlichen Gründen hab ich vor gefühlten 100 Jahren mit plone/zope aufgehört. :mad:

Das Drama ist jedoch eher ein Python als ein FreeBSD Problem, der geneigte Suchroboter wird Tonnen von Treffern mit dem Suchstring UnicodeDecodeError liefern.

Ipython läuft, nur wenn die History sehr wichtig ist halt nicht richtig. pyside wird von pypi geholt und mit pip install pyside im $virtualenv installiert wenn das ganze qt - Gedöns existiert.

hth
 
. pyside wird von pypi geholt und mit pip install pyside im $virtualenv installiert wenn das ganze qt - Gedöns existiert.

So, ich habe das qt4-Geraffel aus den Ports installiert und anschließend im virtualenv pip install pyside ausgeführt. Wie fast schon nicht anders zu erwarten, lief die Installation dann direkt auf den Hammer:

Code:
Failed to query the Qt version with qmake /usr/local/bin/qmake

----------------------------------------
Command /home/xxx/python3/bin/python3.2 -c "import setuptools;__file__='/home/xxx/python3/build/pyside/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-nqs9g1-record/install-record.txt --single-version-externally-managed --install-headers /home/xxx/python3/include/site/python3.2 failed with error code 1 in /home/xxx/python3/build/pyside

Langsam bin ich ratlos, woran das schon wieder liegt :confused:
 
Es ist mit normalem Aufwand nicht machbar :(
Was jetzt kommt, ist stark Gehirnkrebserzeugend und nicht zur Nachahmung empfohlen.

qmake gibt's in FreeBSD nicht, aber qmake-qt4 . Ein ln -s /usr/local/bin/qmake-qt4 virtualenv/bin/qmake wirkt.
Der build brauch devel/shiboken (dann verschwindet auch die nächste Fehlermeldung), nur daß der wieder mit dem Python des Systems (2.7) arbeitet, was am Ende klemmt, da in meinem Fall im virtualenv python3.3 ist.
Jetzt ist es an der Zeit , vom vormals ignorierten python-bug zu einem qt-bug zu kommen, nur der ist nicht ignorierbar.
error: [...]virtualenv/build/pyside/patchelf: No such file or directory

Soweit so gut.
Also nach [...]virtualenv/build/pyside/sources/patchelf/ und dort ein beherztes
g++ -o patchelf patchelf.cc und das generierte patchelf nach [...]virtualenv/build/pyside/ kopiert und schon ist der Bug behoben.

Jetzt arbeitet shiboken aber noch mit dem Systempython, und das ist 2.7. :ugly: und packt seine Ergebnisse pflichtgemäß unter
[...]build/pyside/pyside_install/py33[raffelraffel]/lib/python2.7/site-packages/PySide und das geht hier nun gar nicht.

Möglicherweise, wenn das Systempython komplett auf python3.* umgestellt würde, könnte das funktionieren. Aber jetzt ist meine unbezahlte Neugier erstmal befriedigt :rolleyes:
@morpheus: Du machst das doch bisher in einem Jail ?
Virtualbox mit einem OS, bei dem du sicher bist, dass das geht. Spart in diesem Fall Nerven. :zitter:
 
Zurück
Oben