Artifact-py: a reimagining of artifact

NOTICE: this is in alpha. It works but likely has many bugs and missing features.

This is a reimplementation of artifact in python. It will be the barebones of artifact necessary to put it in a build system. No featureful cli, no web-ui. Just parsing and exporting of json/markdown/etc.

At the same time, this is not a strict rewrite. It is a reimagining and will probably guide the development of artifact 3.0.

Install with pip install artifact_py. It should work in python 2.7+ and 3+

Differences with artifact

The primary differences will be:

• The use of the new anchor_txt markdown attribute format, developed specifically for this project to not have dependencies on any specific markdown implementation.
• Removal of .art/settings.toml, replaced with an attribute block anywhere in the markdown file.
• Massive simpliication of the cmdline tool. This may be improved in the future.
• A few minor tweaks to simplify how artifacts are specified and linked.
  • Markdown can be exported in place -- almost none of the document has to be changed.
  • Artifacts are now specified by the anchor in a header. Conventionally it will look like # This is my spec (SPC-mine) {#SPC-mine}. The {#SPC-mine} is a (not-quite) standard markdown anchor used to create a reference. The (SPC-mine) is by-convention so that humans can see that the header is specifying an artifact.
    • Note: anchor_txt also supported the html anchor <a id="SPC-mine" />, which is what is necessary in github
  • Artifact attributes are specified with a fenced code block. See [SPC-design] for an example.
  • Removal of [[REQ-foo]] references. Instead you just use [@REQ-foo] and art export --format md -i will put your standard markdown reference links at the bottom of your document. (i.e. [@REQ-foo]: url/to/code.py
  • Removal of specifying subparts (formerly called subnames) via [[REQ-foo.subpart]]. Simply specify them in your attributes with partof, and link to the code in your deisign doc with [@REQ-foo.subpart].
  • Has no special support for graphviz.
  • No exporting of the relationship of artifacts to the markdown file itself. In the author's opinion this frequently just added to clutter and was not especially useful.

Overall, this design works much more hand-in-hand with the standard markdown specification. It feels cleaner, and allows for easier conversion from an "arbitrary" design document to one that is rich in links to source code and other designs.

Features still to be added:

• Currently only supports a single markdown file. I also want to re-imagine how large numbers of files/etc could be integrated before adding more files.
• Linting -- no linter currently exists
• text field in the json of artifact. It was not required for any implementation details and may be added later.
• A stable json output format. It is still in flux.

Design (SPC-design)

subparts:
  - artifact
  - settings
  - code
  - lint
  - tst-unittests

All attributes and settings are specified with an anchor_txt code block.

Settings are specified like this, anywhere in the document:

```yaml @
artifact:
  root_dir: ./
  code_paths:
    - src/
```

Artifact attributes like this:

```yaml @
partof:
  - SPC-other

subparts:
  - function
  - tst-unit
```

Settings (SPC-design.settings)

code: @SPC-design.settings

Artifacts are injected from the --doc markdown design document. All settings/attributes are provided using the anchor_txt format. Settings are provided by adding the following to an artifact attribute anywhere in the document:

• root_dir: the root directory when creating paths. This will affect where other path settings use as a reference.
• code_paths: paths to files or directories to look for code. See Code Links for more information.
• exclude_code_paths: paths to exclude when searching for artifacts.

Artifact (SPC-design.artifact)

code: @SPC-design.artifact

An artifact is a piece of documentation that can be linked to other pieces of documentation and to source code. It has the following attributes:

• name: defines how it can be linked. The name is defined in the anchor header ({#REQ-foo})
  • There are three types of artifacts: REQ (requirement), SPC (specification), TST (test)
• partof: the other artifacts this artifact is a partof.
• subparts: pieces of an artifact that can be linked in code.
• done: force an artifact to be considered specified and tested

Code Links (SPC-design.code)

code: @SPC-design.code

Artifacts are linked in code by:

• Defining an artifact name or subpart
• Specifying code_paths in Settings
• Putting a tag anywhere in code of the form:
  • #SPC-foo
  • #SPC-foo.bar

Artifact will run a regular expression over all files found in code_paths and will mark artifacts as specified/tested if they are linked in code.

Lints (SPC-design.lint)

Unit Tests (SPC-design.tst-unittests)

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Metadata

artifact:
  root_dir: './'

  code_paths:
    - artifact_py/
    - tests/

  exclude_code_paths:
    - tests/artifacts_only/
    - tests/projects/
    - tests/test_code.py


  code_url:
    "https://github.com/vitiral/artifact_py/blob/master/{file}#L{line}"