Demande #4840: Revoir la redéfinition des contraintes - creole - Ensemble Ouvert Libre Évolutif

Demande #4840

Revoir la redéfinition des contraintes

Ajouté par Daniel Dehennin il y a environ 11 ans. Mis à jour il y a plus de 8 ans.

Statut:

Fermé

Priorité:

Normal

Assigné à:

Daniel Dehennin

Catégorie:

Version cible:

Début:

Echéance:

% réalisé:

40%

Temps passé:

0.07 h

Description

Suite à la correction des fill et auto (#4774) il est nécessaire de revoir comment est gérée la redéfinition des autres contraintes.

patch.diff Voir (876 octets) Emmanuel GARETTE, 29/05/2013 10:32

Demandes liées

Révisions associées

Révision c2683bcd (diff)
Ajouté par Daniel Dehennin il y a presque 11 ans

Impossible de faire un « hidden_if_in » avec un paramètre hors d’un « valid_enum »

creole/var_loader.py (CreoleVarLoader.update_requires): Ne forcer la
propriété qu’en fonction du paramètre « True/False ».

Ref: #4840 @2m

Historique

#1 Mis à jour par Daniel Dehennin il y a environ 11 ans

Version cible mis à Eole 2.4-dev-2

À inclure dans un sprint.

#2 Mis à jour par Joël Cuissinat il y a environ 11 ans

Version cible changé de Eole 2.4-dev-2 à Eole 2.4-dev-3

#3 Mis à jour par Daniel Dehennin il y a presque 11 ans

Statut changé de Nouveau à En attente d'informations
Assigné à mis à Emmanuel GARETTE

Je ne suis pas sûr que les hidden_if_in fonctionne correctement avec le code actuel.

Par exemple pour la famille interface_1 (eole-common:source:dicos/01_network.xml#L571?rev=8dfa70b3):

On définie que la famille doit être désactivée si la variable nombre_interfaces est égale à 1:

        <condition name='hidden_if_in' source='nombre_interfaces'>
            <param>1</param>
            <target type='family'>Interface-1</target>
        </condition>

La fonction CreoleConstraint.populate_condition() définie une liste contenant un tuple ('disabled', False) (source:creole/var_loader.py#L227?rev=ced77677)
La fonction CreoleVarLoader.update_requires() (source:creole/var_loader.py#L440?rev=ced77677):
- reçoit [('nombre_interfaces', '1', 'disabled', False)] en paramètre
- renvoie les valeurs (source:creole/var_loader.py#L673?rev=ced77677) :
  - props = ['disabled']
  - req = [(<tiramisu.option.ChoiceOption object at 0x1a6fec0>, '1', 'disabled', False)]

Je pense que le test source:creole/var_loader.py#L453?rev=ced77677 devrait prendre en compte la valeur actuelle de l’option opt, car opt.impl_get_values() renvoie la liste des valeurs autorisées par le valid_enum :

(u'2', u'3', u'4', u'5')

La valeur de nombre_interfaces est 2:

(Pdb) pp self.families['general']['vars']['nombre_interfaces']['value']
'2'

Mais le code (source:creole/var_loader.py#L453?rev=ced77677) :

            if isinstance(opt, ChoiceOption) and \
                    val not in opt.impl_get_values() and \
                    not opt.impl_is_openvalues():
                force_properties.append(value[2])

semble forcer la propriété disabled alors qu’il ne devrait pas.

Il est tout à fait possible aussi que je n’ai rien compris, ne sachant pas vraiment à quoi correspond le tuple ('disabled', False) ni ce qu’est sensé faire le code de CreoleVarLoader.update_requires().

#4 Mis à jour par Emmanuel GARETTE il y a presque 11 ans

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Donc je pars du principe que si le test est fait sur valeur non existante, on "disabled" et on ne fait pas de requirements.

('disabled', False) correspond à hidden_if_in (voir ligne 228 du fichier), ('disabled', True) correspond à hidden_if_not_in (voir 2 lignes en dessous).

J'ai bien l'impression qu'il manque un test ligne 453. Il ne faudrait cacher que si la valeur n'existe pas dans le ChoiceOption et que le calcul est de type hidden_if_not_in (donc qu'il y ait True en 2eme valeur du tuple).

J'espère que ce commentaire permettra de résoudre le problème.

#5 Mis à jour par Daniel Dehennin il y a presque 11 ans

Emmanuel GARETTE a écrit :

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Donc je pars du principe que si le test est fait sur valeur non existante, on "disabled" et on ne fait pas de requirements.

('disabled', False) correspond à hidden_if_in (voir ligne 228 du fichier), ('disabled', True) correspond à hidden_if_not_in (voir 2 lignes en dessous).

J'ai bien l'impression qu'il manque un test ligne 453. Il ne faudrait cacher que si la valeur n'existe pas dans le ChoiceOption et que le calcul est de type hidden_if_not_in (donc qu'il y ait True en 2eme valeur du tuple).

Ça me parait assez étrange comme test, peut-être contre intuitif.

Cache la famille Interface_1 si nombre_interfaces est égal à 1.

Peut-importe les valeurs possible de nombre_interfaces, seul la valeur courant est déterminante, et cette valeur courant est vérifié par le valid_enum.

Le soucis de l’approche actuelle, c’est que dès que l’on redéfinie les valeurs possible de nombre_interfaces, il faut refaire tous les hidden_if_in :

00_common : nombre_interfaces in ['1','2','3','4','5'], valeur par défaut 1
01_network : définition de tous les hidden_if_in pour les familles d’interfaces
30_amon : redéfinie nombre_interfaces in ['2','3','4','5'], valeur par défaut 2

Du coup, la famille Inteface_1 est disabled car son hidden_if_in avec le <param>1</param> est fait sur le range ['2','3','4','5'], alors qu’en fait la famille devrait être enabled.

Merci.

#6 Mis à jour par Daniel Dehennin il y a presque 11 ans

Emmanuel GARETTE a écrit :

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Je pense en fait que l’histoire de la liste des valeurs et du open_values n’ont de sens que pour la saisie des valeurs de nombre_interfaces.

Merci.

#7 Mis à jour par Daniel Dehennin il y a presque 11 ans

Cela risque d’être un peu plus compliqué que prévu :

(Pdb) import tiramisu
(Pdb) b tiramisu.option.validate_requires_arg, name == 'interface_1'
Breakpoint 6 at /usr/lib/python2.7/dist-packages/tiramisu/option.py:797
(Pdb) c
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(799)validate_requires_arg()
(Pdb) p name
'interface_1'
(Pdb) p requires
[(<tiramisu.option.ChoiceOption object at 0x34f8890>, '1', 'disabled', False)]
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(811)validate_requires_arg()
-> if not req[0]._validate(req[1]):
(Pdb) 
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(812)validate_requires_arg()
-> raise ValueError(_('malformed requirements second argument '
(Pdb) 
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(813)validate_requires_arg()
-> 'must be valid for option {0}').format(name))
(Pdb) 
ValueError: ValueErr...face_1',)
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(813)validate_requires_arg()
-> 'must be valid for option {0}').format(name))
(Pdb) l
808                 if req[0].impl_is_multi():
809                     raise ValueError(_('malformed requirements option {0} '
810                                        'should not be a multi').format(name))
811                 if not req[0]._validate(req[1]):
812                     raise ValueError(_('malformed requirements second argument '
813  ->                                    'must be valid for option {0}').format(name))
814                 if len(req) == 3:
815                     action = req[2]
816                     inverse = False
817                 elif len(req) == 4:
818                     action = req[2]

#8 Mis à jour par Emmanuel GARETTE il y a presque 11 ans

Fichier patch.diff Voir ajouté

Voici un patch pour résoudre ce bug.

#9 Mis à jour par Joël Cuissinat il y a plus de 10 ans

Assigné à changé de Emmanuel GARETTE à Daniel Dehennin
Version cible changé de Eole 2.4-dev-3 à Eole 2.4-alpha
% réalisé changé de 0 à 40

#10 Mis à jour par Joël Cuissinat il y a plus de 10 ans

Version cible ~~Eole 2.4-alpha~~ supprimé

#11 Mis à jour par Joël Cuissinat il y a plus de 8 ans

Tracker changé de Evolution à Demande
Statut changé de En attente d'informations à Nouveau
Assigné à ~~Daniel Dehennin~~ supprimé

Visiblement le patch a été appliqué depuis un bout de temps : creole:c2683bcd (>= EOLE 2.4.0)

Voir si une vérification supplémentaire et/ou l'ajout d'un test s'imposent avant fermeture définitive !

#12 Mis à jour par Scrum Master il y a plus de 8 ans

Assigné à mis à Daniel Dehennin

#13 Mis à jour par Daniel Dehennin il y a plus de 8 ans

Statut changé de Nouveau à Fermé

Cela fonctionne sur la version 2.5.1.

En ajoutant le dictionnaire suivant /usr/share/eole/creole/dicos/local/99_test.xml :

<?xml version="1.0" encoding="utf-8"?>
<creole>
    <files>
    </files>
    <variables>
        <family name='general'>
            <variable name='nombre_interfaces' redefine='True' mode='basic'>
                <value>2</value>
            </variable>
        </family>
    </variables>
    <constraints>
        <check name="valid_enum" target="nombre_interfaces">
            <param>['2','3','4','5']</param>
        </check>
    </constraints>
</creole>

Formats disponibles : Atom PDF

Lié à creole - Anomalie #4774: Impossible d'écraser un <fill> sur une variable 2.4	Fermé	28/01/2013	08/02/2013
Lié à Documentations - Evolution #4835: Changement de comportement sur lors de la redéfinition d’une variable	Fermé	07/10/2013	11/10/2013
Lié à eole-common - Anomalie #5441: Problème sur le "fill" de "ssl_country_name" [2.4]	Fermé	27/05/2013	31/05/2013
Lié à creole - Anomalie #6016: Impossible de transformer une variable avec valeur par défaut en "auto"	Fermé	16/09/2013
Lié à creole - Anomalie #5848: Problème lié à la redéfinition de "nombre_interfaces" sur Amon	Classée sans suite

Projet

Général

Profil

Distribution EOLE » Commun » creole

Demandes

Rapports personnalisés