buildzr 0.0.6__tar.gz → 0.0.8__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {buildzr-0.0.6 → buildzr-0.0.8}/PKG-INFO +51 -66
- buildzr-0.0.8/README.md +103 -0
- buildzr-0.0.8/buildzr/__about__.py +1 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/dsl.py +331 -180
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/expression.py +50 -22
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/interfaces/__init__.py +0 -4
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/interfaces/interfaces.py +2 -37
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/relations.py +30 -90
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/encoders/encoder.py +24 -4
- buildzr-0.0.8/tests/samples/component_view.py +30 -0
- buildzr-0.0.8/tests/samples/container_view.py +29 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/samples/container_view_sugar.py +4 -11
- buildzr-0.0.8/tests/samples/groups.py +44 -0
- buildzr-0.0.8/tests/samples/implied_relationships.py +31 -0
- buildzr-0.0.8/tests/samples/nested_groups.py +29 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/samples/simple_dsl.py +2 -1
- buildzr-0.0.8/tests/samples/system_context_view.py +32 -0
- buildzr-0.0.8/tests/samples/system_landscape_view.py +41 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/test_dsl.py +311 -416
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/test_explorer.py +12 -26
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/test_expression.py +18 -21
- buildzr-0.0.8/tests/test_typehints.py +194 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/test_views.py +189 -194
- buildzr-0.0.6/README.md +0 -119
- buildzr-0.0.6/buildzr/__about__.py +0 -1
- buildzr-0.0.6/tests/samples/component_view.py +0 -45
- buildzr-0.0.6/tests/samples/container_view.py +0 -40
- buildzr-0.0.6/tests/samples/groups.py +0 -61
- buildzr-0.0.6/tests/samples/implied_relationships.py +0 -46
- buildzr-0.0.6/tests/samples/system_context_view.py +0 -41
- buildzr-0.0.6/tests/samples/system_landscape_view.py +0 -46
- {buildzr-0.0.6 → buildzr-0.0.8}/.gitignore +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/CONTRIBUTING.md +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/LICENSE.md +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/explorer.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/factory/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/dsl/factory/gen_id.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/encoders/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/models/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/models/generate.sh +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/models/models.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/sinks/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/sinks/interfaces.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/buildzr/sinks/json_sink.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/pyproject.toml +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/abstract_builder.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/samples/__init__.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/samples/simple.py +0 -0
- {buildzr-0.0.6 → buildzr-0.0.8}/tests/test_workspaces.py +0 -0
@@ -1,10 +1,11 @@
|
|
1
|
-
Metadata-Version: 2.
|
1
|
+
Metadata-Version: 2.4
|
2
2
|
Name: buildzr
|
3
|
-
Version: 0.0.
|
3
|
+
Version: 0.0.8
|
4
4
|
Summary: Structurizr for the `buildzr`s 🧱⚒️
|
5
5
|
Project-URL: homepage, https://github.com/amirulmenjeni/buildzr
|
6
6
|
Project-URL: issues, https://github.com/amirulmenjeni/buildzr/issues
|
7
7
|
Author-email: Amirul Menjeni <amirulmenjeni@pm.me>
|
8
|
+
License-File: LICENSE.md
|
8
9
|
Keywords: architecture,buildzr,c4model,design,diagram,structurizr
|
9
10
|
Classifier: Development Status :: 3 - Alpha
|
10
11
|
Classifier: License :: OSI Approved :: MIT License
|
@@ -29,13 +30,11 @@ Description-Content-Type: text/markdown
|
|
29
30
|
|
30
31
|
# Structurizr for the `buildzr`s 🧱⚒️
|
31
32
|
|
32
|
-
`buildzr` is a [Structurizr](https://structurizr.com/) authoring tool for Python programmers.
|
33
|
+
`buildzr` is a [Structurizr](https://structurizr.com/) authoring tool for Python programmers. It allows you to declaratively or procedurally author Structurizr models and diagrams.
|
33
34
|
|
34
|
-
If you're not familiar with Structurizr, it is both an open standard (see [Structurizr JSON schema](https://github.com/structurizr/json)) and a [set of tools](https://docs.structurizr.com/usage) for building software architecture diagrams as code. Structurizr derive its architecture modeling paradigm based on the [C4 model](https://c4model.com/), the modeling language for
|
35
|
+
If you're not familiar with Structurizr, it is both an open standard (see [Structurizr JSON schema](https://github.com/structurizr/json)) and a [set of tools](https://docs.structurizr.com/usage) for building software architecture diagrams as code. Structurizr derive its architecture modeling paradigm based on the [C4 model](https://c4model.com/), the modeling language for describing software architectures and the relationships.
|
35
36
|
|
36
|
-
|
37
|
-
leveraging the standard Structurizr JSON schema for interoperability with
|
38
|
-
various rendering and authoring tools.
|
37
|
+
In Structurizr, you define architecture models and their relationships first. And then, you can re-use the models to present multiple perspectives, views, and stories about your architecture.
|
39
38
|
|
40
39
|
# Quick Start 🚀
|
41
40
|
|
@@ -52,15 +51,10 @@ pip install buildzr
|
|
52
51
|
The module `buildzr.dsl` contains all the classes you need to create a workspace containing all the architecture models.
|
53
52
|
|
54
53
|
Below is an example, where we:
|
55
|
-
1. Create the models (`Person`, `SoftwareSystem`s, the `Container`s inside the `SoftwareSystem`, and the relationships between them)
|
54
|
+
1. Create the models (`Person`, `SoftwareSystem`s, the `Container`s inside the `SoftwareSystem`, and the relationships -- `>>` -- between them)
|
56
55
|
2. Define multiple views using the models we've created before.
|
57
56
|
|
58
57
|
```python
|
59
|
-
import os
|
60
|
-
import json
|
61
|
-
|
62
|
-
from buildzr.encoders import JsonEncoder
|
63
|
-
|
64
58
|
from buildzr.dsl import (
|
65
59
|
Workspace,
|
66
60
|
SoftwareSystem,
|
@@ -72,74 +66,65 @@ from buildzr.dsl import (
|
|
72
66
|
Group,
|
73
67
|
)
|
74
68
|
|
75
|
-
|
76
|
-
|
77
|
-
|
78
|
-
|
79
|
-
|
80
|
-
|
81
|
-
|
82
|
-
|
83
|
-
|
84
|
-
|
85
|
-
|
86
|
-
|
87
|
-
|
88
|
-
),
|
89
|
-
|
90
|
-
|
91
|
-
|
92
|
-
|
93
|
-
|
94
|
-
|
95
|
-
|
96
|
-
|
97
|
-
|
98
|
-
|
99
|
-
|
100
|
-
|
101
|
-
|
102
|
-
|
103
|
-
|
104
|
-
|
105
|
-
|
106
|
-
|
107
|
-
|
108
|
-
|
109
|
-
|
110
|
-
),
|
111
|
-
ContainerView(
|
112
|
-
lambda w: w.software_system().webapp,
|
113
|
-
key='web_app_container_view_00',
|
114
|
-
auto_layout='lr',
|
115
|
-
description="Web App Container View",
|
116
|
-
)
|
117
|
-
)\
|
118
|
-
.get_workspace()
|
119
|
-
|
120
|
-
# Save workspace to a JSON file following the Structurizr JSON schema.
|
121
|
-
w.to_json('workspace.json')
|
69
|
+
with Workspace('w') as w:
|
70
|
+
with Group("My Company"):
|
71
|
+
u = Person('Web Application User')
|
72
|
+
webapp = SoftwareSystem('Corporate Web App')
|
73
|
+
with webapp:
|
74
|
+
database = Container('database')
|
75
|
+
api = Container('api')
|
76
|
+
api >> ("Reads and writes data from/to", "http/api") >> database
|
77
|
+
with Group("Microsoft"):
|
78
|
+
email_system = SoftwareSystem('Microsoft 365')
|
79
|
+
|
80
|
+
u >> [
|
81
|
+
desc("Reads and writes email using") >> email_system,
|
82
|
+
desc("Create work order using") >> webapp,
|
83
|
+
]
|
84
|
+
webapp >> "sends notification using" >> email_system
|
85
|
+
|
86
|
+
SystemContextView(
|
87
|
+
software_system_selector=webapp,
|
88
|
+
key='web_app_system_context_00',
|
89
|
+
description="Web App System Context",
|
90
|
+
auto_layout='lr',
|
91
|
+
exclude_elements=[
|
92
|
+
u,
|
93
|
+
]
|
94
|
+
)
|
95
|
+
|
96
|
+
ContainerView(
|
97
|
+
software_system_selector=webapp,
|
98
|
+
key='web_app_container_view_00',
|
99
|
+
auto_layout='lr',
|
100
|
+
description="Web App Container View",
|
101
|
+
)
|
102
|
+
|
103
|
+
w.to_json('workspace.json')
|
122
104
|
```
|
123
105
|
|
124
106
|
Here's a short breakdown on what's happening:
|
125
|
-
- In `Workspace(
|
126
|
-
-
|
127
|
-
-
|
107
|
+
- In the `with Workspace('w') as w:` block, we've created a `Workspace` named `w`.
|
108
|
+
- Inside this block, we're in the context of the `w` workspace, so any models, relationships, and views we declared in this block will belong to that workspace. We've declared a few models: `Person`, the `SoftwareSystems`, their `Container`s, and their relationships with each other. Oh, we've separated them into different `Group`s, too!
|
109
|
+
- Showing the who's and the what's in an architecture model is good, but an architecture model is incomplete without the arrows that describes the relationships between the systems. In `buildzr`, we can define relationships with the `>>` operator.
|
110
|
+
- Once we have all the models and their relationships defined, we use (and re-use!) the static models to create multiple views to tell different stories and show various narrative to help document your software architecture. In this case, we've created one `SystemContextView` and one `ContainerView` for the `webapp`.
|
128
111
|
- Finally, we write the workspace definitions into a JSON file, which can be consumed by rendering tools, or used for further processing.
|
129
112
|
|
130
113
|
The JSON output can be found [here](examples/system_context_and_container_view.json). You can also try out https://structurizr.com/json to see how this workspace will be rendered.
|
131
114
|
|
132
115
|
# Why use `buildzr`?
|
133
116
|
|
134
|
-
✅ Uses
|
117
|
+
✅ Uses `buildzr`'s declarative DSL syntax to help you create C4 model architecture diagrams in Python concisely.
|
118
|
+
|
119
|
+
✅ Uses `buildzr`'s DSL APIs to programmatically create C4 model architecture diagrams. Good if you need to automate things!
|
135
120
|
|
136
121
|
✅ Write Structurizr diagrams more securely with extensive type hints and [mypy](https://mypy-lang.org) support.
|
137
122
|
|
138
123
|
✅ Stays true to the [Structurizr JSON schema](https://mypy-lang.org/) standards. `buildzr` uses the [datamodel-code-generator](https://github.com/koxudaxi/datamodel-code-generator) to automatically generate the "low-level" [representation](buildzr/models/models.py) of the Workspace model. This reduces deprecancy between `buildzr` and the Structurizr JSON schema.
|
139
124
|
|
140
|
-
✅ Writing architecture diagrams in Python allows you to integrate programmability and automation into your software architecture diagramming and documentation workflow.
|
125
|
+
✅ Writing architecture models and diagrams in Python allows you to integrate programmability and automation into your software architecture diagramming and documentation workflow. For example, you might want to programmatically automate the creation of architecture models from metadata pulled from your IT asset management system, but still want to declaratively define how to present them.
|
141
126
|
|
142
|
-
✅ Uses the familiar Python programming language to write software architecture diagrams!
|
127
|
+
✅ Uses the familiar Python programming language and its rich toolchains to write software architecture models and diagrams!
|
143
128
|
|
144
129
|
# Contributing
|
145
130
|
|
buildzr-0.0.8/README.md
ADDED
@@ -0,0 +1,103 @@
|
|
1
|
+
# Structurizr for the `buildzr`s 🧱⚒️
|
2
|
+
|
3
|
+
`buildzr` is a [Structurizr](https://structurizr.com/) authoring tool for Python programmers. It allows you to declaratively or procedurally author Structurizr models and diagrams.
|
4
|
+
|
5
|
+
If you're not familiar with Structurizr, it is both an open standard (see [Structurizr JSON schema](https://github.com/structurizr/json)) and a [set of tools](https://docs.structurizr.com/usage) for building software architecture diagrams as code. Structurizr derive its architecture modeling paradigm based on the [C4 model](https://c4model.com/), the modeling language for describing software architectures and the relationships.
|
6
|
+
|
7
|
+
In Structurizr, you define architecture models and their relationships first. And then, you can re-use the models to present multiple perspectives, views, and stories about your architecture.
|
8
|
+
|
9
|
+
# Quick Start 🚀
|
10
|
+
|
11
|
+
## Installation
|
12
|
+
|
13
|
+
You can use `pip` to install the `buildzr` package:
|
14
|
+
|
15
|
+
```bash
|
16
|
+
pip install buildzr
|
17
|
+
```
|
18
|
+
|
19
|
+
## Creating a workspace
|
20
|
+
|
21
|
+
The module `buildzr.dsl` contains all the classes you need to create a workspace containing all the architecture models.
|
22
|
+
|
23
|
+
Below is an example, where we:
|
24
|
+
1. Create the models (`Person`, `SoftwareSystem`s, the `Container`s inside the `SoftwareSystem`, and the relationships -- `>>` -- between them)
|
25
|
+
2. Define multiple views using the models we've created before.
|
26
|
+
|
27
|
+
```python
|
28
|
+
from buildzr.dsl import (
|
29
|
+
Workspace,
|
30
|
+
SoftwareSystem,
|
31
|
+
Person,
|
32
|
+
Container,
|
33
|
+
SystemContextView,
|
34
|
+
ContainerView,
|
35
|
+
desc,
|
36
|
+
Group,
|
37
|
+
)
|
38
|
+
|
39
|
+
with Workspace('w') as w:
|
40
|
+
with Group("My Company"):
|
41
|
+
u = Person('Web Application User')
|
42
|
+
webapp = SoftwareSystem('Corporate Web App')
|
43
|
+
with webapp:
|
44
|
+
database = Container('database')
|
45
|
+
api = Container('api')
|
46
|
+
api >> ("Reads and writes data from/to", "http/api") >> database
|
47
|
+
with Group("Microsoft"):
|
48
|
+
email_system = SoftwareSystem('Microsoft 365')
|
49
|
+
|
50
|
+
u >> [
|
51
|
+
desc("Reads and writes email using") >> email_system,
|
52
|
+
desc("Create work order using") >> webapp,
|
53
|
+
]
|
54
|
+
webapp >> "sends notification using" >> email_system
|
55
|
+
|
56
|
+
SystemContextView(
|
57
|
+
software_system_selector=webapp,
|
58
|
+
key='web_app_system_context_00',
|
59
|
+
description="Web App System Context",
|
60
|
+
auto_layout='lr',
|
61
|
+
exclude_elements=[
|
62
|
+
u,
|
63
|
+
]
|
64
|
+
)
|
65
|
+
|
66
|
+
ContainerView(
|
67
|
+
software_system_selector=webapp,
|
68
|
+
key='web_app_container_view_00',
|
69
|
+
auto_layout='lr',
|
70
|
+
description="Web App Container View",
|
71
|
+
)
|
72
|
+
|
73
|
+
w.to_json('workspace.json')
|
74
|
+
```
|
75
|
+
|
76
|
+
Here's a short breakdown on what's happening:
|
77
|
+
- In the `with Workspace('w') as w:` block, we've created a `Workspace` named `w`.
|
78
|
+
- Inside this block, we're in the context of the `w` workspace, so any models, relationships, and views we declared in this block will belong to that workspace. We've declared a few models: `Person`, the `SoftwareSystems`, their `Container`s, and their relationships with each other. Oh, we've separated them into different `Group`s, too!
|
79
|
+
- Showing the who's and the what's in an architecture model is good, but an architecture model is incomplete without the arrows that describes the relationships between the systems. In `buildzr`, we can define relationships with the `>>` operator.
|
80
|
+
- Once we have all the models and their relationships defined, we use (and re-use!) the static models to create multiple views to tell different stories and show various narrative to help document your software architecture. In this case, we've created one `SystemContextView` and one `ContainerView` for the `webapp`.
|
81
|
+
- Finally, we write the workspace definitions into a JSON file, which can be consumed by rendering tools, or used for further processing.
|
82
|
+
|
83
|
+
The JSON output can be found [here](examples/system_context_and_container_view.json). You can also try out https://structurizr.com/json to see how this workspace will be rendered.
|
84
|
+
|
85
|
+
# Why use `buildzr`?
|
86
|
+
|
87
|
+
✅ Uses `buildzr`'s declarative DSL syntax to help you create C4 model architecture diagrams in Python concisely.
|
88
|
+
|
89
|
+
✅ Uses `buildzr`'s DSL APIs to programmatically create C4 model architecture diagrams. Good if you need to automate things!
|
90
|
+
|
91
|
+
✅ Write Structurizr diagrams more securely with extensive type hints and [mypy](https://mypy-lang.org) support.
|
92
|
+
|
93
|
+
✅ Stays true to the [Structurizr JSON schema](https://mypy-lang.org/) standards. `buildzr` uses the [datamodel-code-generator](https://github.com/koxudaxi/datamodel-code-generator) to automatically generate the "low-level" [representation](buildzr/models/models.py) of the Workspace model. This reduces deprecancy between `buildzr` and the Structurizr JSON schema.
|
94
|
+
|
95
|
+
✅ Writing architecture models and diagrams in Python allows you to integrate programmability and automation into your software architecture diagramming and documentation workflow. For example, you might want to programmatically automate the creation of architecture models from metadata pulled from your IT asset management system, but still want to declaratively define how to present them.
|
96
|
+
|
97
|
+
✅ Uses the familiar Python programming language and its rich toolchains to write software architecture models and diagrams!
|
98
|
+
|
99
|
+
# Contributing
|
100
|
+
|
101
|
+
Interested in contributing to `buildzr`?
|
102
|
+
|
103
|
+
Please visit [CONTRIBUTING.md](CONTRIBUTING.md).
|
@@ -0,0 +1 @@
|
|
1
|
+
VERSION = "0.0.8"
|