Refactor cli #1

New Issue

blallo · 2019-04-15T18:44:05+02:00

blallo commented

2019-04-15 18:44:05 +02:00

Adesso usiamo un entrypoint scritto manualmente. Nulla di male, ma esiste click, libreria per la costruzione di CLI molto potente.

Lavoro nella branch refactor

Adesso usiamo un entrypoint scritto manualmente. Nulla di male, ma esiste `click`, libreria per la costruzione di CLI molto potente. Lavoro nella branch `refactor`

blallo self-assigned this 2019-04-15 18:44:06 +02:00

blallo added this to the CLI refactor milestone 2019-04-15 18:49:41 +02:00

crudo commented

2019-04-16 20:09:08 +02:00

Hello,

bello ma tutta quella roba dovrebbe andare in un posto diverso: app.py è l'"entrypoint" delle API web, mentre src/phid è il demone che quello che viene invocato da systemd o chi per lui.

Suggerimento: crea un file src/phi che verrà lanciato dall'utente che vuole svolgere operazioni da commandline. La parte di parsing degli argomenti invece la metterei in src/phi/cli.py.

Baci

(PS: bello click ma quando ti trovi 34 decoratori sopra una funzione diventa abbastanza illegibile)

Hello, bello ma tutta quella roba dovrebbe andare in un posto diverso: app.py è l'"entrypoint" delle API web, mentre `src/phid` è il demone che quello che viene invocato da systemd o chi per lui. Suggerimento: crea un file `src/phi` che verrà lanciato dall'utente che vuole svolgere operazioni da commandline. La parte di parsing degli argomenti invece la metterei in `src/phi/cli.py`. Baci (PS: bello click ma quando ti trovi 34 decoratori sopra una funzione diventa abbastanza illegibile)

blallo commented

2019-04-17 17:24:31 +02:00

bello ma tutta quella roba dovrebbe andare in un posto diverso: app.py è l’“entrypoint” delle API web, mentre src/phid è il demone che quello che viene invocato da systemd o chi per lui.

click è integrato con setuptools (guarda qui). Quando fai pip install ti viene messo nel path adeguato un eseguibile chiamato phid che fa esattamente quello che ti aspetti :)

Suggerimento: crea un file src/phi che verrà lanciato dall’utente che vuole svolgere operazioni da commandline. La parte di parsing degli argomenti invece la metterei in src/phi/cli.py.

Potevo scorporare il solo entrypoint def cli(...) in un modulo a parte, come suggerisci, ma dovevo fare una serie di import proprio da app e allora ho valutato di lasciare tutto lì.

(PS: bello click ma quando ti trovi 34 decoratori sopra una funzione diventa abbastanza illegibile)

Vero. A questo temo non ci sia soluzione. E' il modo in cui si usa click, che io sappia.

> bello ma tutta quella roba dovrebbe andare in un posto diverso: app.py è l’“entrypoint” delle API web, mentre src/phid è il demone che quello che viene invocato da systemd o chi per lui. `click` è integrato con `setuptools` (guarda [qui](https://git.abbiamoundominio.org/unit/phi/src/branch/refactor/setup.py#L17)). Quando fai `pip install` ti viene messo nel path adeguato un eseguibile chiamato `phid` che fa esattamente quello che ti aspetti :) > Suggerimento: crea un file src/phi che verrà lanciato dall’utente che vuole svolgere operazioni da commandline. La parte di parsing degli argomenti invece la metterei in src/phi/cli.py. Potevo scorporare il solo entrypoint `def cli(...)` in un modulo a parte, come suggerisci, ma dovevo fare una serie di import proprio da `app` e allora ho valutato di lasciare tutto lì. > (PS: bello click ma quando ti trovi 34 decoratori sopra una funzione diventa abbastanza illegibile) Vero. A questo temo non ci sia soluzione. E' il modo in cui si usa `click`, che io sappia.

crudo commented

2019-04-18 18:57:33 +02:00

click è integrato con setuptools (guarda qui). Quando fai pip install ti viene messo nel path adeguato un eseguibile chiamato phid che fa esattamente quello che ti aspetti :)

Scusa, mi sono espresso male, per me non è un problema di script ma di organizzazione logica del progetto: quello che volevo fare è avere delle api python (quello che trovi attualmente in src/phi/ldap) che possono essere invocate o da commandline o tramite API REST. Quindi dovrebbero essere generati, o creati, due script: phid che è il demone delle API web e phi dovrebbe permettere di fare una roba tipo phi add nomeutente o phi group users add nomeutente.

Mi rendo conto ora che per commandline tu intendi solo il modo di girare su che porta deve ascoltare il server e altri parametri di configurazione, e non l'interfaccia alternativa di cui parlo sopra. Sorry :D

Vedi tu, ricorda solo che:

Explicit is better than implicit.
Simple is better than complex.
Sparse is better than dense.

(import this)

>click è integrato con setuptools (guarda qui). Quando fai pip install ti viene messo nel path adeguato un eseguibile chiamato phid che fa esattamente quello che ti aspetti :) Scusa, mi sono espresso male, per me non è un problema di script ma di organizzazione logica del progetto: quello che volevo fare è avere delle api python (quello che trovi attualmente in `src/phi/ldap`) che possono essere invocate o da commandline o tramite API REST. Quindi dovrebbero essere generati, o creati, due script: phid che è il demone delle API web e phi dovrebbe permettere di fare una roba tipo `phi add nomeutente` o `phi group users add nomeutente`. Mi rendo conto ora che per commandline tu intendi solo il modo di girare su che porta deve ascoltare il server e altri parametri di configurazione, e non l'interfaccia alternativa di cui parlo sopra. Sorry :D Vedi tu, ricorda solo che: ``` Explicit is better than implicit. Simple is better than complex. Sparse is better than dense. ``` (`import this`)

blallo commented

2019-04-19 16:07:48 +02:00

Ho capito. Allora vuoi fare una suite di cli. Bello (guarda qui).

Potremmo proprio fare un package dedicato in src/phi/cli allora. Facciamo un modulo per la cli del demone ed uno per la cli del controller.

Ho capito. Allora vuoi fare una suite di cli. Bello (guarda [qui](https://git.abbiamoundominio.org/blallo/BotZ/src/branch/master/bot_z/cli.py)). Potremmo proprio fare un package dedicato in `src/phi/cli` allora. Facciamo un modulo per la cli del demone ed uno per la cli del controller.

blallo commented

2019-04-19 16:10:30 +02:00

Come facciamo comunicare il controller (phi) con il demone (phid)?

HTTP su localhost
HTTP su socket unix (si può fare)
Sistema di named pipe
...?

Proponi. Sono aperterrimo.

Come facciamo comunicare il controller (`phi`) con il demone (`phid`)? 1. HTTP su localhost 2. HTTP su socket unix (si può fare) 3. Sistema di named pipe 4. ...? Proponi. Sono aperterrimo.

crudo commented

2019-04-19 16:42:14 +02:00

Di fatto non c'è nessun controller e nessun demone. Come dicevo l'ambaradam si riduce a:

Semplici funzioni python che permettono di svolgere operazioni elementari (aggiungi utente, aggiungi gruppo, aggiungi utente a gruppo, etc). Trovi questa parte in src/phi/ldap. Faccio presente alcune cose:

<inizio excursus>

connection.py contiene le funzioni che permettono di stabilire una nuova connessione col server LDAP.
client.py contiene una classe che non fa altro che invocare le funzioni in connection.py con i parametri corretti, fornendo una interfaccia facilitata.
entry.py permette di accedere direttamente a entità LDAP. Dal punto di vista di LDAP, tutto è una entry (potrebbe non essere il termine corretto da RFC, ma rende l'idea). Gli utenti sono entry con certi attributi (mail, password, etc) e i gruppi sono entry con certi altri attributi (utenti dentro al gruppo, etc)
user.py contiene le funzioni che permettono di manipolare ciò che è per noi un utente, cioè una entry con determinati attributi. Dovremmo farne uno anche per i gruppi ed eventualmente altri se troviamo necessario estendere la nostra astrazione.

Nota anche come la programmazione a oggetti è del tutto assente e superflua, l'unica classe è Client in client.py puramente per una questione di comodità. Tutti gli altri componenti che interagiscono col LDAP sono funzioncine pure.

<fine excursus>

Interfaccia API REST che data una certa conf (coordinate e credenziali del server ldap, etc) permette di invocare le sopracitate funzioni (POST /user/name, POST /group/name, PUT /group/nomegruppo, etc)
Interfaccia da linea di comando che non fa altro che invocare le funzioncine di cui sopra (sempre data una certa conf bla bla).

Di fatto non c'è nessun controller e nessun demone. Come dicevo l'ambaradam si riduce a: * Semplici funzioni python che permettono di svolgere operazioni elementari (aggiungi utente, aggiungi gruppo, aggiungi utente a gruppo, etc). Trovi questa parte in src/phi/ldap. Faccio presente alcune cose: `<inizio excursus>` * connection.py contiene le funzioni che permettono di stabilire una nuova connessione col server LDAP. * client.py contiene una classe che non fa altro che invocare le funzioni in connection.py con i parametri corretti, fornendo una interfaccia facilitata. * entry.py permette di accedere direttamente a entità LDAP. Dal punto di vista di LDAP, tutto è una entry (potrebbe non essere il termine corretto da RFC, ma rende l'idea). Gli utenti sono entry con certi attributi (mail, password, etc) e i gruppi sono entry con certi altri attributi (utenti dentro al gruppo, etc) * user.py contiene le funzioni che permettono di manipolare ciò che è per *noi* un utente, cioè una entry con determinati attributi. Dovremmo farne uno anche per i gruppi ed eventualmente altri se troviamo necessario estendere la nostra astrazione. Nota anche come la programmazione a oggetti è del tutto assente e superflua, l'unica classe è Client in client.py puramente per una questione di comodità. Tutti gli altri componenti che interagiscono col LDAP sono funzioncine pure. `<fine excursus>` * Interfaccia API REST che data una certa conf (coordinate e credenziali del server ldap, etc) permette di invocare le sopracitate funzioni (POST /user/name, POST /group/name, PUT /group/nomegruppo, etc) * Interfaccia da linea di comando che non fa altro che invocare le funzioncine di cui sopra (sempre data una certa conf bla bla).

blallo commented

2020-11-26 19:01:12 +01:00

Direi che questa si può chiudere per inattività.

blallo closed this issue

2020-11-26 19:01:13 +01:00

Sign in to join this conversation.