attributes cannot be overridden by 'doorstop add' command

[tangoalx]

Intro

When I set attributes in a .doorstop file, then I cannot use the doorstop add -d defaults.yml REQ command to use a different set of default attributes for a newly created requirement.

Basically the -d option works as expected, if no default values have been set in the .doorstop file.

I'm using doorstop version 2.2b5.

My setup

.doorstop

settings:
  digits: 3
  prefix: REQ
  sep: '-'
attributes:
  !include ../defaults-req.yml

defaults-req.yml

  defaults:
    header: |
      Please insert an expressive short header here
    text: |
      Please insert your requirement text here
    custom-attribute-1: |
      Please insert a value here
    custom-attribute-2: |
      Please insert a value here
  publish:
    - custom-attribute-1
    - custom-attribute-2
  reviewed:
  - custom-attribute-1
  - custom-attribute-2

defaults.yml

  defaults:
    header: ''
    text: |
      Please insert your header text here
    normative: false

Run

command line:

doorstop add -d defaults.yml REQ
added item: REQ-001 (@\req\REQ-001.yml)

Result

When I look into the item, then I see that instead of applying defaults.yml, the defaults-req.yml is applied, but the defaults.yml has been just copied as a whole in the yml file.

REQ-001.yml

active: true
defaults:
  header: ''
  text: |
    Please insert your header text here
  normative: false
derived: false
header: |
  Please insert an expressive short header here
level: 1.0
links: []
normative: true
ref: ''
reviewed: null
text: |
  Please insert your requirement text here
custom-attribute-1: |
  Please insert a value here
custom-attribute-2: |
  Please insert a value here

Expected

A command line option must always override the default values otherwise the option is pointless.

REQ-001.yml

active: true
derived: false
header: ''
level: 1.0
links: []
normative: false
ref: ''
reviewed: null
text: |
  Please insert your header text here

[tangoalx]

@jacebrowning: I think I can get a solution for that quickly. But I would like to hear your opinion on that:

1. Default values given by command line option -d are just taken from the given defaults.yml file as it is - the yml attribute "defaults" is not expected in that file. That is inconsistent to the way we include defaults in the .doorstop file, which demands a defaults-req.yml file which contains the yml attribute defaults as top level element. I would like to harmonize that. This also requires adaption of documentation here.

2. From my understanding a command line option overwrites stored defaults completely. The idea behind the example leading to this bug is a very practical one: I want to be able to set defaults for normative requirements, but in case of non-normative ones, I want to be able to set different defaults. As normative and non-normative requirements are exclusive, I also need the defaults to be exclusive. I can also imagine different types of requirements being exclusive and requiring a template, so that the requirement engineer can apply that quickly. On the other hand, I can also imagine user-scenarios demanding to add further defaults on top of already given ones. There are several ways a user would still be able to accomplish that (e.g. providing more different default files, or even extracting common attributes into files and use the pyyaml include technique).

[tangoalx]

1. Default values given by command line option -d are just taken from the given defaults.yml file as it is - the yml attribute "defaults" is not expected in that file. That is inconsistent to the way we include defaults in the .doorstop file, which demands a defaults-req.yml file which contains the yml attribute defaults as top level element. I would like to harmonize that. This also requires adaption of documentation here.

That's not really an issue to be honest. That just found out that it was my misusage - it is possible to get around it, if designing the yml more elegant.

[jacebrowning]

The fix for this is available here: https://pypi.org/project/doorstop/3.0a2/