flag parse + log module + configuration file

[MrPetru]

ho diviso il codice in una seria di branch che però vengono uno dietro al altro ... in modo da mantenere più semplice i eventuali merge. vediamo se possiamo lavorare cosi o devo modificarli diversamente.

[lento]

sto lavorando a questa pull request nel mio fork perche' lavorando al "supervisor" mi e' venuta un'idea: le parti comuni (log, configurazione, ecc.) dovrebbero essere in un repo "maponet/utils" a parte, cosi' possiamo riutilizzarli nelle varie applicazioni.

Per usare questa struttura possiamo cambiare gli import cosi':

import (
    "maponet/mapo/admin"
    "maponet/utils/conf"
    "maponet/utils/log"
)

e ristrutturare la nostra copia locale:

$GOPATH
├── bin
├── pkg
└── src
    └── maponet
        ├── mapo
        │   └── mapo.go
        └── utils
            ├── conf
            │   └── conf.go
            └── log
                └── log.go

tra poco vedrai queste modifiche in lento/mapo

[lento]

alcuni commenti sparsi:

• cos'e' gconf/conf?
• mi puoi fare un esempio del panic con il livello di log troppo alto?
• assicurati di formattare i file con gofmt prima di fare commit (magari c'e' un plugin per integrare gofmt nel tuo editor)
• la parte della configurazione non va dentro mapo/admin/admin.go, come dicevamo admin e' solo per le API della parte amministrativa. Tutto quello che fa parte del core dell'applicazione va in un apposito file nella root (e' proprio per rendere questa differenza piu' esplicita che ho rinominato core -> admin) :)
  Un esempio sarebbe mapo/conf.go, ma in questo caso specifico conf.go andra' nel suo pacchetto a parte (vedi commento precedente)

Non perdere tempo su questi commenti, sono cose semplici che posso fare io nel mio fork e mandarti le modifiche.

[MrPetru]

2013/1/31 Lorenzo Pierfederici notifications@github.com

sto lavorando a questa pull request nel mio fork perche' lavorando al
"supervisor" mi e' venuta un'idea: le parti comuni (log, configurazione,
ecc.) dovrebbero essere in un repo "maponet/utils" a parte, cosi' possiamo
riutilizzarli nelle varie applicazioni.

Per usare questa struttura possiamo cambiare gli import cosi':

import (
"maponet/mapo/admin"
"maponet/utils/conf"
"maponet/utils/log"
)

e ristrutturare la nostra copia locale:

$GOPATH
├── bin
├── pkg
└── src
└── maponet
├── mapo
│ └── mapo.go
└── utils
├── conf
│ └── conf.go
└── log
└── log.go

tra poco vedrai queste modifiche in lento/mapo

come posso dirlo in una maniera più delicata? :) magari: io l'avevo
proposto di scrivere tutto in una maniera più modulare. cosi, se c'è
bisogno di riutilizzare qualche modulo da qualche altra parte potremo farlo
nel futuro. ma a quel tempo si pensava che non si riutilizzerà da
nessun'altra parte. l'unico che l'ho scritto come un modulo indipendente è
il modulo log. questa perché non avevo scelta. il modulo log dovevo
importarlo in tutti altri e mi creava degli errori ciclici di importazione.

una domanda. il supervisor? da quello che capisco è un altra applicazione,
non è lo stesso mapo che viene avviato in una modalità speciale del tipo
master o slave (default) ? il suo lavoro sarà quello di controllare
è organizzare il lavoro delle istanze di mapo.

se è un'altra applicazione allora la struttura delle cartelle proposta mi
sembra corretta apparte il fatto che possiamo sotto lineare il suo
collegamento con mapo e avere meno repositori da gestire, tramite le
seguente modifiche:

$GOPATH
└── src
├── mapo
│ ├── mapo.go
│ ├── conf
│ │ └──conf.go
│ └── log
│ └──log.go
└── supervisor

secondo me questa ci porta ad avere:

• un repositori in meno da gestire
• i path di import sono es: import "mapo/conf"
• supervisor usa i moduli direttamente da mapo, cosi sottolineammo la loro
  relazione (almeno che non vogliamo farlo un'applicazione indipendente da
  mapo).

per la cartella maponet, il discorso è: come ci organizziamo il codice?
a. se uso il git per gestire il mio repo, uso il commando "git clone git://
github.com/maponet/mapo.git"
b. se uso il go per scaricare il codice "go get github.com/maponet/mapo"
differenza è che go forza il mantenimento delle path che è $GOPATH/src/
github.com/maponet/mapo è il path di import diventa import "
github.com/maponet/mapo". Mentre git mette il codice scaricato li dove tu
li lo dici (es: ./mapo).
io per il momento non ho maponet o gitthub.com nelle mie path di import...
mi servono?

dimmi cosa ne hai in mente per il supervisor? cosi posso esprimere il mio
giudizio finale su struttura delle cartelle è il repositori utils.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4#issuecomment-12929703.

[MrPetru]

2013/1/31 Lorenzo Pierfederici notifications@github.com

alcuni commenti sparsi:

• cos'e' gconf/conf?
• la parte della configurazione non va dentro mapo/admin/admin.go,
  come dicevamo admin e' solo per le API della parte amministrativa.
  Tutto quello che fa parte del core dell'applicazione va in un apposito file
  nella root (e' proprio per rendere questa differenza piu' esplicita che ho
  rinominato core -> admin) :) Un esempio sarebbe mapo/conf.go, ma
  in questo caso specifico conf.go andra' nel suo pacchetto a parte
  (vedi commento precedente)

gconf/conf è una libreria per leggere è scrivere i file di configurazione.
ecco il link https://code.google.com/p/goconf/ ... quando lo scaricato mi
sono sbagliato è a posto di goconf ho scritto gconf. mi sono accorto
soltanto ora. l'ho usata principalmente per non stare a perdere tempo ora
su di una funzionalità del genere, per vedere se l'idea di usare un file di
configurazione funziona/serve per mapo.

• mi puoi fare un esempio del panic con il livello di log troppo alto?

tu hai proposto soltanto 3 liveli do log: INFO, ERROR e DEBUG ... che
anche io stavo pensando che sono sufficienti. e qui non c'è niente da dire.
Se una persona per sbaglio usa un livelo per log diverso da questi? mapo
può essere avviato con il flag -log=2 per esempio. l'utente si potrebbe
anche sbagliare e scrivere -log=21 o -log=12 ... quale è il livelo di log
in questo caso? si potrebbe continuare l'avio con il valore di default ma
quasi probabilmente non sarà il log desiderato. e ho deciso di usare un
panic, ma basterebbe anche un return per chiudere l'applicazione in maniera
meno invasiva con il messaggio della descrizione del errore.

• assicurati di formattare i file con gofmt prima di fare commit
  (magari c'e' un plugin per integrare gofmt nel tuo editor)

sicuramente lo faro. tu usi qualche plugin per vim che gia fa questo
lavoro?

Non perdere tempo su questi commenti, sono cose semplici che posso fare io
nel mio fork e mandarti le modifiche.

se la separazione dei branch che ho fatto per i primi due pull request può
andare bene allora io posso fare pull request di altri moduli (gli ho
separato tutti più o meno in moduli individuali)

[lento]

ho estratto log e l'ho inserito in maponet/utils.

b. se uso il go per scaricare il codice "go get github.com/maponet/mapo" differenza è che go forza il
mantenimento delle path che è $GOPATH/src/ github.com/maponet/mapo è il path di import diventa import "
github.com/maponet/mapo". Mentre git mette il codice scaricato li dove tu li lo dici (es: ./mapo). io per il
momento non ho maponet o gitthub.com nelle mie path di import... mi servono?

In effetti non c'e' motivo per non rendere questi pacchetti go-gettable, anzi! Rende tutto piu' comodo. Quindi ho modificato la mia copia locale:

$GOPATH
├── bin
├── pkg
└── src
    └── github.com
        └── maponet
            ├── mapo
            │   └── mapo.go
            └── utils
                └── log
                    └── log.go

e ho cambiato l'import path del pacchetto log in mapo.go (per ora solo nella mia copia locale):

import (
    "github.com/maponet/utils/log"
)

e faro' lo stesso con conf

sicuramente lo faro. tu usi qualche plugin per vim che gia fa questo lavoro?

c'e' una serie di plugin per vim inclusi nella distribuzione di go, basta aggiungere questo a .vimrc

filetype off
filetype plugin indent off 
set rtp+=$GOROOT/misc/vim
filetype plugin indent on
syntax on

riguardo al settare il livello di log, dai un'occhiata a quello che ho fatto con numeri e stringhe, e a FlagLevel(), che nella mia copia locale di mapo uso cosi':

    var logLevel = log.FlagLevel()
    flag.Parse()
    err := log.SetLevelString(*logLevel)
    if err != nil {
        log.Fatal(err.Error())
    }

Settare un livello di default non e' necessario, l.level di default e' 0 (log.ERROR, e questo tra l'altro e' il motivo per cui ho invertito l'ordine dei livelli rispetto alla tua versione e ho cominciato da ERROR a salire).