Ecco lo scenario:Quale dovrebbe essere il mio percorso LESS @import?
Sto eseguendo Django 1.3.1, utilizzando file statici e django-compressor (ultima versione stabile) per, tra le altre cose, compilare file LESS.
Ho una directory "assets" che è collegata a file statici con STATICFILES_DIRS
(per risorse statiche a livello di progetto). In quella directory ho una directory "css" e in quella un file "lib.less" che contiene le variabili LESS e i mixin.
Quindi il percorso fisico è <project_root>/assets/css/lib.less
ed è servito allo /static/css/lib.less
.
In una delle directory statiche delle mie app, ho un altro file LESS che deve importare quello in alto. Il percorso fisico per questo è <project_root>/myapp/static/myapp/css/file.less
e verrà servito allo /static/myapp/css/file.less
.
Il mio primo pensiero è stato:
@import "../../css/lib.less"
(vale a dire in base alla URL, salire a livelli da /static/myapp/css
a /static/
, poi traversare giù in /static/css/lib.less
).
Tuttavia, questo non funziona, e ho provato praticamente tutte le combinazioni di URL e percorsi fisici a cui riesco a pensare e tutti loro mi danno FilterError
s nel modello, risultanti dal non riuscire a trovare il file da importare.
Qualcuno ha qualche idea su quale dovrebbe essere il percorso di importazione effettivo?
Blah! Penso che dovrò fare lo stesso ... Il mio compilatore di dev locale non è a conoscenza dei file statici di django .. quindi anche se ho modificato il mio flusso di lavoro per eseguire collectstatic localmente, il mio compilatore avrebbe modificato i file nella directory/static /. Un po 'sfortunato. Hai finito per utilizzare ancora i file statici per tutto tranne i CSS? –
Alla fine ho spostato i miei file meno in 'assets/less/products.less' e rimosso la struttura della cartella dell'app. Un'app con tutte le sue risorse sembra così pulita, è troppo male se n'è andata! –
Forse mi manca qualcosa, ma perché non configurare semplicemente 'lessc' con alcuni percorsi di inclusione che lo rendono così non devi usare quei percorsi relativi? Potrebbe non essere ideale o namespace-y, ma nemmeno la tua soluzione. – tmandry