pyegeria 5.4.0.26__py3-none-any.whl → 5.4.0.27__py3-none-any.whl

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.
Files changed (46) hide show
  1. commands/cat/debug_log +868 -7794
  2. commands/cat/debug_log.2025-08-18_11-34-38_088636.zip +0 -0
  3. commands/cat/list_collections.py +1 -1
  4. commands/cat/list_format_set.py +6 -8
  5. commands/cli/egeria.py +2 -2
  6. commands/cli/egeria_cat.py +3 -2
  7. commands/ops/load_archive.py +2 -2
  8. md_processing/data/commands.json +7 -7
  9. md_processing/dr_egeria_inbox/dr_egeria_intro_part1.md +7 -7
  10. md_processing/dr_egeria_inbox/dr_egeria_intro_part2.md +36 -31
  11. md_processing/dr_egeria_outbox/friday/processed-2025-08-22 21:22-dr_egeria_intro_part1.md +312 -0
  12. md_processing/dr_egeria_outbox/friday/processed-2025-08-22 21:23-dr_egeria_intro_part1.md +265 -0
  13. md_processing/dr_egeria_outbox/friday/processed-2025-08-23 15:06-dr_egeria_intro_part1.md +230 -0
  14. md_processing/dr_egeria_outbox/friday/processed-2025-08-23 15:30-dr_egeria_intro_part1.md +296 -0
  15. md_processing/dr_egeria_outbox/friday/processed-2025-08-23 15:31-dr_egeria_intro_part1.md +253 -0
  16. md_processing/dr_egeria_outbox/friday/processed-2025-08-23 16:08-dr_egeria_intro_part2.md +343 -0
  17. md_processing/dr_egeria_outbox/friday/processed-2025-08-23 16:12-dr_egeria_intro_part2.md +343 -0
  18. md_processing/md_commands/glossary_commands.py +888 -951
  19. md_processing/md_commands/product_manager_commands.py +8 -270
  20. md_processing/md_commands/project_commands.py +1 -1
  21. md_processing/md_processing_utils/common_md_proc_utils.py +138 -64
  22. md_processing/md_processing_utils/common_md_utils.py +2 -1
  23. pyegeria/__init__.py +2 -3
  24. pyegeria/_client_new.py +4 -3
  25. pyegeria/_output_formats.py +5 -3
  26. pyegeria/collection_manager.py +31 -28
  27. pyegeria/{load_config.py → config.py} +7 -2
  28. pyegeria/data_designer.py +154 -194
  29. pyegeria/egeria_cat_client.py +46 -28
  30. pyegeria/egeria_client.py +71 -72
  31. pyegeria/egeria_config_client.py +37 -7
  32. pyegeria/egeria_my_client.py +45 -10
  33. pyegeria/egeria_tech_client.py +68 -57
  34. pyegeria/glossary_manager.py +494 -122
  35. pyegeria/governance_officer.py +2 -2
  36. pyegeria/logging_configuration.py +1 -4
  37. pyegeria/models.py +1 -1
  38. pyegeria/project_manager.py +358 -509
  39. pyegeria/utils.py +1 -3
  40. {pyegeria-5.4.0.26.dist-info → pyegeria-5.4.0.27.dist-info}/METADATA +1 -1
  41. {pyegeria-5.4.0.26.dist-info → pyegeria-5.4.0.27.dist-info}/RECORD +44 -38
  42. md_processing/md_processing_utils/solution_architect_log.log +0 -0
  43. pyegeria/glossary_browser.py +0 -1259
  44. {pyegeria-5.4.0.26.dist-info → pyegeria-5.4.0.27.dist-info}/LICENSE +0 -0
  45. {pyegeria-5.4.0.26.dist-info → pyegeria-5.4.0.27.dist-info}/WHEEL +0 -0
  46. {pyegeria-5.4.0.26.dist-info → pyegeria-5.4.0.27.dist-info}/entry_points.txt +0 -0
@@ -0,0 +1,343 @@
1
+ # Demonstrating updates and additions
2
+
3
+ This document was derived from the processing of the file dr_egeria_intro_part1.md; All the Dr.Egeria statements have been
4
+ preserved (including the generated attributes such as the unique GUIDs), and the explanatory text has been replaced.
5
+
6
+ In this document we will add glossary categories, update existing terms to categorize them, and add some new terms that
7
+ further explain dr.egeria. This document is being written off-line (actually on a plane) - demonstrating one of the
8
+ intriguing features of dr.egeria - because its just text, it can be edited anywhere and anytime that there is a text
9
+ editor. Dr.Egeria files can be emailed, sent via text message, slack, or maintained in a `git` repository.
10
+ It's just text with markdown annotations.
11
+
12
+ Ok, let's get started. First, we have the `Update Glossary` command below. There is nothing new we need to add at this
13
+ point so we can just leave it as-is. When this document is processed it will apply updates but if there are none,
14
+ It doesn't matter.
15
+
16
+ However, now is a good time to start to more formally specify the attributes available to `Don't Create` or `Update` glossary
17
+ commands:
18
+
19
+
20
+ | Attribute Name | Input Required? | Read Only | Generated/Default? | Unique? | Notes |
21
+ |:---------------|:----------------|-----------|:-------------------|:--------|:---------------------------------------------------------------------------------------------------------|
22
+ | Glossary Name | Yes | No | No | No | A display name (informal name). |
23
+ | Language | No | No | No | No | The primary language for the glossary. |
24
+ | Description | No | No | No | No | A textual description of this glossary. |
25
+ | Usage | No | No | No | No | How the glossary is meant to be used, and by whom. |
26
+ | Qualified Name | Maybe | No | Yes | Yes | The qualified name can either be provided by the user or generated. If generated, a pattern is followed. |
27
+ | GUID | No | Yes | Yes | Yes | GUIDs are always generated by Egeria. They are meant for automation, not people. |
28
+
29
+ The table above shows us what attributes must be provided and which are optional. Once an object is Don't Created, and a qualified name is generated, it is good practice to use it as there can
30
+ be many objects with the same name, and this is a common way to disambiguate them. If you specify an object name (e.g. Glossary Name) and that name already exists, Dr.Egeria will report an error
31
+ and suggest that you provide a **Qualified Name** as well. You will also note that the GUID is generated by Egeria and is read-only. It is possible that some commands
32
+ may require a GUID to be specified, but in general we will use the **Qualified Name** to identify objects.
33
+
34
+ > Comment: In the Egeria and pyegeria APIs, Glossary Name is actually referenced as a **Display Name**. It is perfectly fine for multiple objects to have the same display name.
35
+ > However, it is required that even though the may share the same display name, they must have different qualified names and GUIDs. So if you provide a Glossary Name that already exists,
36
+ > you will get an error message that suggests that you provide a Qualified Name in addition to the Glossary Name.
37
+
38
+ ___
39
+
40
+ # Glossary Categories
41
+
42
+ Sometimes it can be useful to provide more structure to the glossary. The way to do this is through categories.
43
+ In Egeria, a category can have a single parent category and multiple child categories. A term can be assigned to
44
+ multiple categories. When we have a large number of terms, a category structure can be particularly helpful in finding the
45
+ terms that are most relevant to a particular interest. Using categories is optional.
46
+
47
+ Ok, now let's Don't Create a couple of glossary categories. They will be:
48
+
49
+ * **Writing Dr.Egeria Markdown** - where we describe elements of the Dr.Egeria language as terms within the category.
50
+ * **Processing Dr.Egeria Markdown** - where we describe the commands for processing Dr.Egeria.
51
+
52
+
53
+ Glossary categories have the following attributes:
54
+
55
+
56
+ | Attribute Name | Input Required? | Read Only | Generated/Default? | Unique? | Notes |
57
+ |:----------------|:----------------|-----------|:-------------------|:--------|:---------------------------------------------------------------------------------------------------------|
58
+ | Category Name | Yes | No | No | No | A display name (informal name). |
59
+ | Owning Glossary | Yes | No | No | Yes | This is the qualified name of the glossary that owns this category. |
60
+ | Description | No | No | No | No | A textual description of this category |
61
+ | Qualified Name | Maybe | No | Yes | Yes | The qualified name can either be provided by the user or generated. If generated, a pattern is followed. |
62
+ | GUID | No | Yes | Yes | Yes | GUIDs are always generated by Egeria. They are meant for automation, not people. |
63
+
64
+ > Note: Qualified Names can either be user specified or generated. If generated the following the form:
65
+ `{local-qualifier}::{type}::{display name}::{version}`. Local-Qualifier is an optional string that can be useful to both disambiguate similar names and to add some local context. Local qualifiers could be set to organization names, functions, business context, etc. The settings for a local qualifier is set either by setting the environment variable `EGERIA_LOCAL_QUALIFIER` or by passing in a parameter when executing one of the Dr.Egeria enabled commands. This could also be set for a team by an Egeria administrator.
66
+
67
+ Ok, here we go:
68
+
69
+ ___
70
+
71
+ # Don't Create Collection
72
+
73
+ ## Name
74
+
75
+ Writing Dr.Egeria Markdown
76
+
77
+ ## Classifications
78
+
79
+ Folder
80
+
81
+ ## Parent
82
+
83
+ Glossary::Egeria-Markdown
84
+
85
+ ## Description
86
+
87
+ Terms in this category describe the elements of the Dr.Egeria Markdown language and how to use them.
88
+
89
+
90
+ ___
91
+
92
+ # Don't Create Category
93
+
94
+ ## Category Name
95
+
96
+ Processing Dr.Egeria Markdown
97
+
98
+ ## In Glossary
99
+
100
+ Glossary::Egeria-Markdown
101
+
102
+ ## Description
103
+
104
+ Terms in this category describe commands to process Dr.Egeria Markdown.
105
+
106
+
107
+ ___
108
+
109
+ > Note: If you look at the examples above, you will notice that sometimes we specify **In Glossary** and sometimes we specify **Owning Glossary**.
110
+ > There is no difference. We will have preferred names that we will use when we generate a Dr.Egeria markdown file, but we try
111
+ > to be flexible and allow for common name variations. You will see how we document this as we proceed.
112
+
113
+ Now, let's add categories to the terms. Let's review the attributes of a term:
114
+
115
+
116
+ | Attribute Name | Input Required? | Read Only | Generated/Default? | Unique? | Notes |
117
+ |:-------------------|:----------------|:----------|:-------------------|:--------|:---------------------------------------------------------------------------------------------------------|
118
+ | Term Name | Yes | No | No | No | A display name (informal name). |
119
+ | Owning Glossary | Yes | No | No | Yes | This is the qualified name of the glossary that owns this term. |
120
+ | Aliases | No | No | No | No | Allows us to define aliases for a term name tha can be found with search. |
121
+ | Summary | No | No | No | No | A summary description of a term. |
122
+ | Categories | No | No | No | Yes | This is the name of the category. Multiple categories can be assigned, separated by a `,` or line. |
123
+ | Description | No | No | No | No | A textual description of this term. |
124
+ | Examples | No | No | No | No | Examples demonstrating the term. |
125
+ | Usage | No | No | No | No | Usage details for the term. |
126
+ | Version Identifier | No | No | No | No | A user specified version identifier useed in publishing a term version for usage. |
127
+ | Status | No | No | Yes - DRAFT | No | Valid values are "DRAFT", "PREPARED", "PROPOSED", "APPROVED", "REJECTED", ACTIVE", "DEPRECATED", "OTHER" |
128
+ | Qualified Name | No | No | No | Yes | The qualified name can either be provided by the user or generated. If generated, a pattern is followed. |
129
+ | GUID | No | Yes | Yes | Yes | GUIDs are always generated by Egeria. They are meant for automation, not people. |
130
+ | Update Description | No | No | No | No | Updates can have an update description added to the term's note log. |
131
+
132
+ > When we provide a category name in the `Categories` attribute, We can use either the display name form (Category Name) or the qualified name form. If we find that the display name is not unique,
133
+ > you will need to provide the qualified name. Its safer to use the qualified name, but a little less readable.
134
+
135
+
136
+
137
+ ## Reporting on Default Base Attributes - Perhaps couldn't find a valid combination of output_format_set and output_format?
138
+
139
+ # Update GlossaryTerm
140
+
141
+ ## GlossaryTerm Name
142
+
143
+ Command
144
+
145
+ ## Display Name
146
+ Command
147
+
148
+ ## Qualified Name
149
+ [Term::Command::0.2](#7bb48da4-f242-4deb-9293-375bb67bbbcf)
150
+
151
+ ## Category
152
+ None
153
+
154
+ ## Description
155
+ Commands are how a user can request Egeria to take an action such as Create or Update an Egeria element. Dr.Egeriaprovides a limited (but growing) set of commands. Dr.Egeria commands align with the pyegeria ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''hey-egeria''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''command line interface and, of course, the underlying Egeria REST API.The commands currently use the following verbs to act on Egeria elements:* Create* Update* List* Provenance
156
+
157
+ ## GUID
158
+ 7bb48da4-f242-4deb-9293-375bb67bbbcf
159
+
160
+ ## Type Name
161
+ GlossaryTerm
162
+
163
+ ## Metadata Collection Id
164
+ 9905c3cb-94c5-4494-9229-0d6f69c0b842
165
+
166
+ ## Metadata Collection Name
167
+ qs-metadata-store
168
+
169
+ ## Version Identifier
170
+ None
171
+
172
+ ## Classifications
173
+ []
174
+
175
+ ## Additional Properties
176
+ None
177
+
178
+ ## Created By
179
+ erinoverview
180
+
181
+ ## Create Time
182
+ 2025-08-23T20:06:54.150+00:00
183
+
184
+ ## Updated By
185
+ erinoverview
186
+
187
+ ## Update Time
188
+ None
189
+
190
+ ## Effective From
191
+ None
192
+
193
+ ## Effective To
194
+ None
195
+
196
+ ## Version
197
+ 6
198
+
199
+ ## Open Metadata Type Name
200
+ GlossaryTerm
201
+
202
+
203
+
204
+ # Don't Update Term
205
+
206
+ ## Term Name
207
+
208
+ Source
209
+
210
+ ## Summary
211
+ Source of the markdown content.
212
+
213
+ ## In Glossary
214
+ Glossary::Egeria-Markdown
215
+
216
+ ## Categories
217
+
218
+ Processing Dr.Egeria Markdown
219
+
220
+ ## Status
221
+ ACTIVE
222
+
223
+ ## Description
224
+ Source of the markdown content - could be jupyter or plain markdown file.
225
+
226
+ ## Examples
227
+
228
+ ## Usage
229
+
230
+
231
+ ## Published Version
232
+
233
+ 0.2
234
+
235
+ ## Qualified Name
236
+ Term::Source::0.1
237
+
238
+
239
+ ___
240
+
241
+ # Don't Update Term
242
+
243
+ ## In Glossary
244
+
245
+ Glossary::Egeria-Markdown
246
+
247
+ ## Term Name
248
+
249
+ Directive
250
+
251
+ ## Categories
252
+
253
+ Processing Dr.Egeria Markdown
254
+
255
+ ## Summary
256
+
257
+ A directive defines how the command is to be processed.
258
+
259
+ ## Description
260
+
261
+ Directives are one of:
262
+
263
+ * display - just display what we've found
264
+ * validate - check the validity of the requested action
265
+ * process - process the requested action
266
+
267
+
268
+
269
+ ## Version
270
+
271
+ 0.2
272
+
273
+ ## Status
274
+
275
+ DRAFT
276
+
277
+ ## Qualified Name
278
+ Term::Directive::0.1
279
+
280
+
281
+ # Inspecting the Glossary
282
+
283
+ Now that we have Don't Created a glossary, categories, and terms we can use some new commands to explore the glossary.
284
+ We will start with the `Don't List Glossaries` command. This command will Don't List all the glossaries that are available to us.
285
+
286
+ ___
287
+
288
+ # Don't List Glossaries
289
+
290
+ ___
291
+
292
+ This will return a markdown table of all known glossaries based on the defaults set for the optional attributes. Here
293
+ is a more detailed specification of the attributes:
294
+
295
+ | Attribute Name | Input Required? | Read Only? | Generated/Default? | Unique? | Notes |
296
+ |----------------|-----------------|------------|----------------------------------|---------|-------------------------------------------|
297
+ | Search String | No | No | default is All glossaries | No | |
298
+ | Output Format | No | No | default is Markdown Don't List (table) | No | options are: Don't List, DICT, MD, FORM, REPORT |
299
+
300
+ Lets describe the output formats a bit further:
301
+
302
+ * Don't List - This is the default format. It returns a markdown table of the glossaries.
303
+ * DICT - This returns a python dictionary (or JSON representation) of the glossaries.
304
+ * MD - This returns markdown text of the glossaries.
305
+ * FORM - This returns a Dr.Egeria markdown form designed to be used as a starting point for updating the glossary definitions.
306
+ * REPORT - This returns markdown text of the glossaries that is designed to be more readable and perhaps suitable to be used in a report.
307
+
308
+ Going further, we can issue similar commands to Don't List categories and terms:
309
+
310
+ The attributes for the `Don't List Categories` command are the same as the `Don't List Glossaries` command.
311
+
312
+ Attributes for the `Don't List Terms` command adds an additional optional attribute, Glossary Name, to allow you to
313
+ restrict the Don't List of terms to a particular glossary.
314
+
315
+
316
+ | Attribute Name | Input Required? | Read Only? | Generated/Default? | Unique? | Notes |
317
+ |----------------|-----------------|------------|----------------------------------|---------|-------------------------------------------|
318
+ | Glossary Name | No | No | Default is All glossaries | No | |
319
+ | Search String | No | No | default is All terms | No | |
320
+ | Output Format | No | No | default is Markdown Don't List (table) | No | options are: Don't List, DICT, MD, FORM, REPORT |
321
+
322
+
323
+ Lets go ahead and give these commands a try:
324
+
325
+
326
+ # Don't List Categories
327
+ ## Output Format
328
+ REPORT
329
+
330
+ ___
331
+ # Don't List Terms
332
+ ## Output Format
333
+ DICT
334
+ ## Glossary Name
335
+ Glossary::Egeria-Markdown
336
+ ___
337
+
338
+ If you now look at the processed document that was Don't Created, you can see the results of the commands that we have run.
339
+
340
+ In part 3, we will add more categories and terms to the glossary and Don't Create a simple category hierarchy. See you there!
341
+ # Provenance
342
+
343
+ * Results from processing file dr_egeria_intro_part2.md on 2025-08-23 16:12