Currently, the following can happen:

$ git checkout branch1
$ doorstop add HLR
Added HLR042
$ git add HLR042
git commit ...

$ git checkout branch2
$ doorstop add HLR
Added HLR042  # from this working copy HLR041 was the last added
$ git add HLR042
git commit ...

The same scenario could happen in the same branch, but across repositories. What are some options to prevent this and/or produce a warning?

TODO:

• update CLI to support: doorstop add PREFIX --count=5

https://pythonhosted.org/an_example_pypi_project/sphinx.html#python-cross-referencing-syntax

This screws up the import because there's no easy way to determine where the separation between requirements is.

For example, an item might be created to wrap a block of code for linking purposes. How can this item follow a block of code as it:

• moves in a file
• its file gets moved
• its file gets renamed
• the block of code changes insignificantly

This can already be done using a unique string and Item.ref, but that requires adding metadata to the source code.

I tried creating two doorstop documents in the folder and got an error. I don't understand why this shouldn't be allowed.

Use case:
You have the following:
1.1 SWR333
1.2 SWR334
1.3 SWR335

and you want to insert SWR336 as 1.2 and move the rest down.

TODO:

• fix pylint duplicate code warnings
• fix scrutinizer C and D issues

http://nbviewer.ipython.org/gist/jacebrowning/9754157 at the very end, line 58, shows how to extend issues. Only when I try it, profiling shows that I never actually called anything.

My code

@theovoss @robertberrington How about:

$ doorstop trace LLR123
LLT123:
    child_links:
    - LLT001
    - LLT002
    parent_links:
    - HLR001
    - HLR002

$ doorstop trace LLR
LLR001:
    child_links:
    - LLT001
    - LLT002
    parent_links:
    - HLR001
    - HLR002
...
LLR999:
    child_links:
    - LLT004
    parent_links: []

$ doorstop trace all
SYS001:
...
SYS999:
...
HLR001:
...
LLR001:
...
LLR999:
...

$ doorstop trace all path/to/report.xlsx

File output would be in the format of: #20 (comment)

Perhaps file output is all that's really needed?

At least with CSV, export to import of 1.0 results in 1. This might be a limitation of the format if CSV editors coerce number-like strings to numbers.

Determine if ReqIF is widely used and makes sense to support for import/export: http://www.omg.org/spec/ReqIF/

I'm installing with both

pip install Doorstop

and

python setup.py install

and getting this error

Traceback (most recent call last):
  File "setup.py", line 9, in <module>
    from doorstop import __project__, __version__, CLI, GUI
  File "/Users/elewis/doorstop/doorstop/__init__.py", line 12, in <module>
    from doorstop.core import Item, Document, Tree
  File "/Users/elewis/doorstop/doorstop/core/__init__.py", line 3, in <module>
    from doorstop.core.item import Item
  File "/Users/elewis/doorstop/doorstop/core/item.py", line 46
    raise DoorstopError(msg) from None
                                ^
SyntaxError: invalid syntax

I'm don't really know much about python, except that it's really picky about whitespace, so wondering if you have any idea if I'm doing something wrong or is there a problem with /core/item.py or some other file(s)?

It was noticed that in one situation the force line breaks in YAML, e.g:

text: |
  This is a sentence with
  a line break.

showed up in the XLSX export. These line breaks should be joined before export.

Another question about my repository and publishing (as HTML) vs. what I see in your doorstop repository. When you have a link to another requirement it's actually generated/rendered as a hypertext link to the referenced requirement page, whereas mine are not.

Again, I'm sure I'm doing something wrong. Just can't find documentation that helps explain exactly what.

Without knowing which document to add all the issues to, weird formats like REQ2-001, break the assumption that the item prefix is the document prefix because the prefix for REQ2-001 is REQ2 but the document for it is 'REQ'

The follow keeps getting reimplemented in different modules:

• level formatting: '.'.join(str(n) for n in level)
• level comparison: level1 > level2
• level shifting: level[-1] += 1

This logic could be moved to Level class.

The head attribute would be used for publishing headers on every Item such as:

1.0 Requirements

1.1 REQ001 Start Up

The product shall start up...

1.2 REQ002 Shutdown

The product shall shut down...

1.3 REQ003

The product shall also...

Attribute could be called:

• Item.head
• Item.heading
• Item.header

Consider aliasing Item.text as Item.body.

I just learned about keyword-only arguments and this seems to be much nicer than using kwargs.get(): http://legacy.python.org/dev/peps/pep-3102/

The doorstop.core.vcs.* code needs to be tested by mocking out calls to subprocess and simulating the behavior of each VCS.

TODO:

• wait for #23

So when I'm working on fixing issues that doorstop shows, I want to work on one type at a time and to know roughly how many places that issue type exist.

For example, currently I don't care about any tracing to the design document, so I've done some basic text filtering to ignore that.

It'd be nice to be able to have a dictionary of issues and save each key as a different file so I can go through and fix one type of issue at a time.

Key = issue type
Value = sub-section of the current tree.issues list that corresponds to the key's issue type

Perhaps keep the current functionality as well.

I've been looking through the help, doorstop-demo, and whatever other documentation I can find for doorstop and can't seem to find any clues about how to control whether you get a "verbose" heading for a section (a parent I believe?) vs. just getting the filename for the heading, when publishing.

I think I've followed the steps outlined in the documentation, e.g.

doorstop new REQ ./req
doorstop add REQ
doorstop edit REQ1
doorstop new TST ./req/tst -parent REQ
doorstop add TST
doorstop edit TST1
etc...

I suspect the key is hidden somewhere in the way I'm initiating the repository/project with

doorstop new REQ ./req

and the relationships created between the parent and children.

doorstop new TST ./req/tst --parent REQ

I can see from doorstop-demo that the "verbose headings" are typically (always?) at the x.0 level and the heading text itself is in the text attribute of the .yml file. However, nothing I have tried has been successful in creating the more verbose headings. Nor have I been able to find instructions on how to make it happen. Can you help point me in the right direction here? I know I'm doing something wrong, just can't seem to see what that is.

Fails : doorstop publish LLR test.html --html

Succeeds : doorstop publish LLR thing/test.html --html

jkloo@ComputerTown ~/projects/super-cool-project/reqs
$ doorstop publish LLR test.html --html
Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Python34\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Python34\Scripts\doorstop.exe\__main__.py", line 9, in <module>
  File "C:\Python34\lib\site-packages\doorstop\cli\main.py", line 149, in main
    success = function(args, os.getcwd(), parser.error)
  File "C:\Python34\lib\site-packages\doorstop\cli\main.py", line 431, in _run_publish
    report.publish(documents[0], args.path, ext, **kwargs)
  File "C:\Python34\lib\site-packages\doorstop\core\report.py", line 34, in publish
    os.makedirs(dirpath)
  File "C:\Python34\lib\os.py", line 237, in makedirs
    mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: ''
publishing LLR to test.html...

jkloo@ComputerTown ~/projects/super-cool-project/reqs
$ doorstop publish LLR thing/test.html --html
publishing LLR to thing/test.html...

This will allow documents to be created out of order and display warnings instead of exiting with an error.

Example usage: $ doorstop edit PREFIX123 --text="This is the first or updated text of this requirement."

I tried to do a loop over tree.issues to output them to a file and I got the following error.

May be related to issue #55 since Jace was debugging that with me this morning and this was working last night.

This should display 3 warnings (if auto-leveling is disabled):

1.0
 1.1
 1.3  # skipped number
3.0  # skipped number
  3.1
  3.1  # duplicate number

TODO:

• add '--section=LEVEL' argument to edit, clear, and review
• define selections as a list where: item.level >= LEVEL < item.level

If HTML, create an index.html.

root and path seem redundant with the PREF parameter. suggest removing root and path.

Separator and req length seem to be document properties to me, not individual Item properties.

Req length could also be considered a range. so when a project rolls over from 100's to 1000's of requirements you don't have to go back and modify hundreds of files to the new length.

Split from #88.

TODO:

• figure out why copied (by travis) files render incorrectly: http://doorstop.info/docs/
• add Doorstop to ReadTheDocs

This may not be appropriate here, but that kind of thing has never stopped me before. ;-/ Feel free to ignore/delete this if it's completely out of place. However, I'm asking here because I think it's relevant to this toolset. I've enjoyed digging into the doorstop app and trying to put it to work. I've also downloaded the doorstop-demo repository and been working with through that quite a bit.

Just wondering if there is anywhere that I could see what a "real" requirements repository might look like, that uses doorstop? And by that I mean, how are people typically writing actual project requirements with this toolset? While the doorstop-demo illustrates the structure of a repository, without actual project requirements it's difficult (for me) to visualize what the requirement content might/should look like. Again, the doorstop-demo gives some clues and is appreciated.

P.S. a Google search is just a little too overwhelming to be very useful. Again, ignore/close/delete if this is too off-topic.

Such as:

document.title = "My Requirements"

Example .doorstop.yml file:

settings:
...
defaults:
  custom-attr1: True
  custom-attr2: "Hello, world!"

Example usage:

item = document.add_item()
assert item.get('custom-attr2') == "Hello, world!"

As a followup to my earlier question on links and headings, it seems that this is an "illegal" construct for doorstop:

active: true
derived: false
level: 1.0
links:
- BSNS001
normative: false
ref: ''
text: |
  All Requirements

What I mean is that when I publish a repository with this kind of requirement the normative attribute somehow overrides the fact that there's a link and the generated page has the appropriate heading but the link is not rendered. Again, I'm probably doing it wrong, but wondering if this is in fact "illegal" should there be some sort of enforcement and/or error message when publishing?

I tried using nano and vi. nano totally screwed up the shell session:

Vim just quit immediately with a "Error reading input, exiting..." message.

New behavior:

doorstop edit <ID>  # opens only Item.text in an editor

doorstop edit --all <ID>  # opens Item.path in an editor (current behavior)

During Item validation, see if we can check for common formatting mistakes:

# mismatched formatting
**word*

# missing list separator
invalid list:
  - item1
  - item2