Dsmr-reader: Pip install psycopg2 vervangen door OS package

Created on 6 Jun 2020  路  8Comments  路  Source: dsmrreader/dsmr-reader

Onderzoeken of het mogelijk is om python3-psycopg2 te gebruiken als alternatief. Dit scheelt weer een dependency die zelf gecompiled moet worden.

bc-break

Most helpful comment

Op Ubuntu 16.04 is dat wel een probleem dan ja, dan zou psycopg2-binary weer een betere oplossing zijn. Moet je nog wel de libpq-library als requirement erbij zetten (vermoed ik). Ik weet niet of libpq standaard meekomt als package, maar dat zal wel denk ik. Op CentOS kun je die los installeren namelijk.

Doel was in elk geval om al dat compile-gebeuren kwijt te raken :-)

All 8 comments

Door de package python3-psycopg2 te installeren en de virtualenv aan te maken met --system-site-packages ipv --no-site-packages hoeven alle development-spullen er niet opgezet te worden. Zaken zoals gcc, g++, cpp en verschillende dev-packages (zoals postgresql-dev) zijn niet meer nodig. Ik heb dit met getest op Ubuntu 18.04 en ik heb de volgende packages ook meegenomen vanuit het OS, die heel erg dicht of helemaal in de buurt kwamen van de verwachte packages in base.txt:

  • python3-serial
  • python3-coreapi
  • python3-crcmod

In relatie tot site-packages is tegenwoord --system-site-packages de standaard. --no-site-packages is tegenwoordig deprecated en zou niet meer gebruikt moeten worden. En het scheelt een hoop gecompile door de psycopg2 vanuit het OS mee te nemen! De overige pip-packages zijn allemaal native python, dus daar hoeft weinig meer voor te gebeuren dan downloaden.

In veel OS'en heet de package psycopg2 ook gewoon python3-psycopg2. Alleen in Alpine Linux (voor Docker) heet die py3-psycopg2.

Bedankt voor je toevoeging. Ik heb het inmiddels ook werkend gekregen op mijn PC (Ubuntu) en Pi (Raspbian).

Voor nu houd ik het alleen bij psycopg2 omdat ik daar echt de meerwaarde van zie van het niet meer hoeven compilen van/met de dev-package.
De andere packages laat ik voor wat het is en houd ik voor nu via pip. Deze wijziging is namelijk al ingrijpend en spannend genoeg, zowel voor nieuwe installaties als bestaande, waarbij gebruikers hun virtualenv opnieuw moeten aanmaken.

Daarom neem ik het mee met de v4.x release, waarbij gebruikers toch al wat handwerk moeten doen om te upgraden.

@rippiedoos ik kom nog wel een interessante situatie tegen voor Ubuntu 16.4. Daar is Python3.5 nog standaard, maar DSMR-reader is Python 3.6.

Als ik dan sudo apt-get install python3-psycopg2 doe dan pakt die de 3.5 versie en in de virtualenv lijkt dat dan mis te gaan.

Gezien deze LTS nog maar een jaar ondersteund wordt en de volgende LTS standaard Python 3.6 heeft, lijkt het me geen groot issue. In het ergste geval wijs ik gebruikers wel op het installeren en compilen via pip, zoals het was.

Ik zie trouwens ook dat psycopg2-binary via PIP mogelijk hetzelfde doet.

Op Ubuntu 16.04 is dat wel een probleem dan ja, dan zou psycopg2-binary weer een betere oplossing zijn. Moet je nog wel de libpq-library als requirement erbij zetten (vermoed ik). Ik weet niet of libpq standaard meekomt als package, maar dat zal wel denk ik. Op CentOS kun je die los installeren namelijk.

Doel was in elk geval om al dat compile-gebeuren kwijt te raken :-)

@rippiedoos ik merk toch steeds meer en meer de nadelen van --system-site-packages.

Ik kom issues tegen zoals:

  • dennissiemensma/dsmr-reader/issues/1078 waarbij Gunicorn niet te gebruiken is op het hardcoded pad dat in Supervisor staat.
  • lokaal bij mij werkte pytest niet meer door een of ander conflict met de systeemversie.

Ik zal daarom kijken of het later weer zonder kan en dan eventueel psycopg2-binary gebruiken als alternatief.

Waarom wordt dan ook supervisor gebruikt? Systemd gebruiken lijkt mij een stuk handiger.

Lijkt erop dat er geknoei gaat komen OS-versies en dat het op een bepaalde manier niet meer gaat werken. Persoonlijk zou ik die hard coded paden dus niet gebruiken in zowel supervisor en/of systemd maar het PATH aanpassen zodat de virtualenv/bin vooraan staat.

Bedankt voor je terugkoppeling. De reden dat er Supervisor wordt gebruikt is omdat het een eenvoudig en vooral robuust stukje software is wat zichzelf al lange tijd heeft bewezen en vrij standaard is.

Dat zeggende hebben, voor Gunicorn zijn er inmiddels meerdere mogelijkheden, waar Systemd ook als alternatief staat. Echter, Supervisor is zoveel eenvoudiger te beheren dan systemd, maar ik wil er nog wel een keer opnieuw naar kijken.

En je suggestie voor het path is nog wel een goede, die zal ik ook nog proberen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PhyxionNL picture PhyxionNL  路  10Comments

dennissiemensma picture dennissiemensma  路  4Comments

Calimerorulez picture Calimerorulez  路  9Comments

joep2000 picture joep2000  路  11Comments

KobeBergmans picture KobeBergmans  路  4Comments