Gestione di più app che annullano i comandi di gestione in Django

Ho un problema in cui c'è più di un'app che tenta di sovrascrivere lo stesso comando di gestione in un progetto Django.Gestione di più app che annullano i comandi di gestione in Django

Ci sono modi adeguati per affrontare questo?
Quale priorità viene assegnata: l'app è stata definita per la prima volta in INSTALLED_APPS o è stata definita per ultima?
È possibile suddividere in modo efficace il comando di gestione definito più di recente anziché semplicemente sostituirlo?

per il contesto che sto cercando di ottenere django_pdb (vedi github) per lavorare in modo più piacevolmente con south e django.contrib.staticfiles.

fonte

2011-12-29 Tom Christie

Perché si rinominano i comandi di gestione esistenti? Per favore, non farlo. Si prega di fornire nomi univoci per i comandi ed evitare questo problema. –

Penso che sia una cosa abbastanza ragionevole da voler dare dato il contesto. (Aggiungendo opzioni --pdb ai comandi test e runserver esistenti) App come 'south' e' django.contrib.staticfiles' fanno esattamente questo, quindi non sono venduto su una coperta "non fare quella" risposta. –

@SLOTT se il codice è completamente in controllo sviluppatore, questa è una domanda molto stupida: basta rinominare uno di essi. Penso che stia cercando di chiedergli cosa fare quando usi due app di comunità che forniscono entrambi comandi "load_sample_data". – Ted

La risposta più semplice di cui sono a conoscenza è: strutturare il progetto in modo da poterne modificare uno e tenere traccia delle modifiche in modo da poterlo applicare alle versioni future.

per i miei progetti mi piace avere:

/myproject 
    /lib 
    /app1 
    /app2 
    /app3

Quindi aggiungere in modo esplicito/lib al percorso in setup.py

import os 
PROJECT_PATH = os.path.realpath(os.path.dirname(__file__)) 

import sys 
lib_dir = os.path.join(PROJECT_PATH, 'lib') 
if lib_dir not in sys.path[:4]: 
    sys.path.insert(1, os.path.join(PROJECT_PATH, 'lib'))

io sono probabilmente molto più probabile rispetto alla media per prendere un app, installalo, quindi cambia il 10% di esso per funzionare esattamente come voglio.

Il vantaggio di questo è: 1) la maggior parte delle dipendenze nave con il codice e sono tracciati in GIT 2) nessuna possibilità per un sistema di un'ampia variazione di causare inaspettatamente bug in un app, se si eseguono più applicazioni dalla stessa macchina e 3) Facile da modificare, con cronologia delle revisioni, qualsiasi cosa nell'app.

Non avendo immerso troppo a fondo i comandi di gestione di sud e non avendo mai usato django_pdb, il tuo particolare problema potrebbe non essere risolto con l'approccio "crea una copia locale e rinominare uno di loro", ma lo condivido nel caso in cui ciò potrebbe accadere.

fonte

2011-12-29 17:31:03 Ted

Grazie per il suggerimento. Questo potrebbe andar bene se stai lavorando su un singolo progetto, ma non aiuta se stai scrivendo un'app riutilizzabile che vuoi che altri installino. (Come nel mio caso d'uso) –

2.5 anni dopo, ma nel caso qualcuno abbia lo stesso problema e atterra qui dopo una ricerca su google, ho creato una piccola app django per trattare con quel caso: django-mcmo ('Gestione di comandi con sovrascrittura multipla'), disponibile su pypi. Ha limitazioni ma funziona come previsto.

Funziona con django 1.4 a 1.8 e py 2 e 3, contributi benvenuto su bitbucket repo.

fonte

2014-08-11 03:08:21 ouk

Gestione di più app che annullano i comandi di gestione in Django

risposta

Problemi correlati