Projet

Général

Profil

Development #6467

Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger

Ajouté par Serghei Mihai il y a environ 9 ans. Mis à jour il y a environ 9 ans.

Statut:
Rejeté
Priorité:
Normal
Assigné à:
Début:
10 février 2015
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Renommer la commande implementée dans le ticket #6340 pour ne pas avoir de conflit des noms des commandes des applications.
Cette commande pourrait être utilisée par une application afin d'implementer la logique de deploiement du tenant


Fichiers

Historique

#1

Mis à jour par Serghei Mihai il y a environ 9 ans

Placée dans le __init__, la classe peut être héritée par les commandes de deploiement des applications

#2

Mis à jour par Frédéric Péters il y a environ 9 ans

Il me semble que ce patch supprime la commande, ça ne me semble pas l'affaire souhaitée. Par ailleurs je ne vois pas pourquoi une commande tierce ne pourrait pas hériter de la classe définie dans deploy.py, quel est le soucis ?

#3

Mis à jour par Serghei Mihai il y a environ 9 ans

En effet, ça supprime la commande de l'application tenant_schemas et laisse la possibilité à une autre application, par exemple authentic, de la rajouter.
Cela m'évite à avoir à gerer l'ordre dans lequel les commandes des applications sont appelées.

#4

Mis à jour par Frédéric Péters il y a environ 9 ans

Mais l'idée c'était d'avoir dans python-entrouvert une commande de base, satisfaisant les besoins communs (combo, passerelle, etc.), ce que tu retires, non ?

#5

Mis à jour par Serghei Mihai il y a environ 9 ans

Cette commande de base ne fait que créer le tenant(schéma + répertoire).
Ensuite chaque application (combo, passerrelle, ...) implemente ses particularités de deploiement, comme par exemple l'ajout d'authentic en tant qu'idp, via la méthode deploy_tenant

#6

Mis à jour par Frédéric Péters il y a environ 9 ans

On va donc avoir dans passerelle, dans combo, dans corbo, dans etc. le même code, qui va faire un create_tenant puis ajouter la conf django-mellon ? Je ne trouve pas que ça soit adéquat, et vraiment dommage quand la seule raison donnée soit de ne pas avoir à s'interroger sur l'ordre de chargement des applications dans authentic.

#7

Mis à jour par Serghei Mihai il y a environ 9 ans

  • Statut changé de Nouveau à Rejeté

Je pensais que chaque application avait plus de configs à faire au niveau de deploy_command.
On peut ignorer ce patch.

Formats disponibles : Atom PDF