argmerge 0.0.0__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.
- argmerge-0.0.0/.coveragerc +13 -0
- argmerge-0.0.0/.github/workflows/build.yml +48 -0
- argmerge-0.0.0/.github/workflows/github-actions-demo.yml +18 -0
- argmerge-0.0.0/.gitignore +209 -0
- argmerge-0.0.0/LICENSE +21 -0
- argmerge-0.0.0/PKG-INFO +101 -0
- argmerge-0.0.0/README.md +82 -0
- argmerge-0.0.0/docs/examples.md +235 -0
- argmerge-0.0.0/docs/img/argmerge.svg +263 -0
- argmerge-0.0.0/docs/img/bracket-logo.svg +27 -0
- argmerge-0.0.0/docs/img/favicon-.ico +0 -0
- argmerge-0.0.0/docs/img/favicon.ico +0 -0
- argmerge-0.0.0/docs/img/initial-description1.svg +4638 -0
- argmerge-0.0.0/docs/img/logo.svg +8567 -0
- argmerge-0.0.0/docs/index.md +78 -0
- argmerge-0.0.0/docs/stylesheets/extra.css +6 -0
- argmerge-0.0.0/main.py +10 -0
- argmerge-0.0.0/mkdocs.yml +39 -0
- argmerge-0.0.0/pyproject.toml +47 -0
- argmerge-0.0.0/src/argmerge/__init__.py +6 -0
- argmerge-0.0.0/src/argmerge/base.py +38 -0
- argmerge-0.0.0/src/argmerge/cli.py +93 -0
- argmerge-0.0.0/src/argmerge/decorator.py +134 -0
- argmerge-0.0.0/src/argmerge/env.py +103 -0
- argmerge-0.0.0/src/argmerge/func.py +126 -0
- argmerge-0.0.0/src/argmerge/json.py +85 -0
- argmerge-0.0.0/src/argmerge/py.typed +0 -0
- argmerge-0.0.0/src/argmerge/trace.py +138 -0
- argmerge-0.0.0/src/argmerge/utils.py +13 -0
- argmerge-0.0.0/src/argmerge/yaml.py +87 -0
- argmerge-0.0.0/tests/__init__.py +1 -0
- argmerge-0.0.0/tests/base/__init__.py +0 -0
- argmerge-0.0.0/tests/base/test_base.py +19 -0
- argmerge-0.0.0/tests/cli/__init__.py +0 -0
- argmerge-0.0.0/tests/cli/test_cli.py +54 -0
- argmerge-0.0.0/tests/decorator/__init__.py +0 -0
- argmerge-0.0.0/tests/decorator/test_decorator.py +212 -0
- argmerge-0.0.0/tests/env/__init__.py +1 -0
- argmerge-0.0.0/tests/env/test_env.py +152 -0
- argmerge-0.0.0/tests/func/__init__.py +1 -0
- argmerge-0.0.0/tests/func/test_func.py +130 -0
- argmerge-0.0.0/tests/json/__init__.py +1 -0
- argmerge-0.0.0/tests/json/bad_config.json +2 -0
- argmerge-0.0.0/tests/json/good_config.json +7 -0
- argmerge-0.0.0/tests/json/test_json.py +91 -0
- argmerge-0.0.0/tests/trace/__init__.py +1 -0
- argmerge-0.0.0/tests/trace/test_trace.py +44 -0
- argmerge-0.0.0/tests/utils.py +12 -0
- argmerge-0.0.0/tests/yaml/__init__.py +1 -0
- argmerge-0.0.0/tests/yaml/bad_config.yaml +6 -0
- argmerge-0.0.0/tests/yaml/good_config.yaml +4 -0
- argmerge-0.0.0/tests/yaml/test_yaml.py +92 -0
- argmerge-0.0.0/threshold.json +4 -0
- argmerge-0.0.0/threshold.yaml +2 -0
- argmerge-0.0.0/tox.ini +27 -0
- argmerge-0.0.0/uv.lock +1618 -0
@@ -0,0 +1,48 @@
|
|
1
|
+
name: build
|
2
|
+
|
3
|
+
on:
|
4
|
+
push:
|
5
|
+
tags:
|
6
|
+
- v*
|
7
|
+
|
8
|
+
concurrency:
|
9
|
+
group: build-${{ github.head_ref }}
|
10
|
+
|
11
|
+
jobs:
|
12
|
+
build:
|
13
|
+
name: Build wheels and source distribution
|
14
|
+
runs-on: ubuntu-latest
|
15
|
+
|
16
|
+
steps:
|
17
|
+
- uses: actions/checkout@v4
|
18
|
+
|
19
|
+
- name: Install build dependencies
|
20
|
+
run: python -m pip install --upgrade build
|
21
|
+
|
22
|
+
- name: Build
|
23
|
+
run: python -m build
|
24
|
+
|
25
|
+
- uses: actions/upload-artifact@v4
|
26
|
+
with:
|
27
|
+
name: artifacts
|
28
|
+
path: dist
|
29
|
+
if-no-files-found: error
|
30
|
+
|
31
|
+
publish:
|
32
|
+
name: Publish release
|
33
|
+
needs:
|
34
|
+
- build
|
35
|
+
runs-on: ubuntu-latest
|
36
|
+
|
37
|
+
steps:
|
38
|
+
- uses: actions/download-artifact@v4
|
39
|
+
with:
|
40
|
+
name: artifacts
|
41
|
+
path: dist
|
42
|
+
|
43
|
+
- name: Push build artifacts to PyPI
|
44
|
+
uses: pypa/gh-action-pypi-publish@release/v1
|
45
|
+
with:
|
46
|
+
skip-existing: true
|
47
|
+
user: __token__
|
48
|
+
password: ${{ secrets.PYPI_API_TOKEN }}
|
@@ -0,0 +1,18 @@
|
|
1
|
+
name: GitHub Actions Demo
|
2
|
+
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
|
3
|
+
on: [push]
|
4
|
+
jobs:
|
5
|
+
Explore-GitHub-Actions:
|
6
|
+
runs-on: ubuntu-latest
|
7
|
+
steps:
|
8
|
+
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
|
9
|
+
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
|
10
|
+
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
|
11
|
+
- name: Check out repository code
|
12
|
+
uses: actions/checkout@v5
|
13
|
+
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
|
14
|
+
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
|
15
|
+
- name: List files in the repository
|
16
|
+
run: |
|
17
|
+
ls ${{ github.workspace }}
|
18
|
+
- run: echo "🍏 This job's status is ${{ job.status }}."
|
@@ -0,0 +1,209 @@
|
|
1
|
+
# Byte-compiled / optimized / DLL files
|
2
|
+
__pycache__/
|
3
|
+
*.py[codz]
|
4
|
+
*$py.class
|
5
|
+
|
6
|
+
# C extensions
|
7
|
+
*.so
|
8
|
+
|
9
|
+
# Distribution / packaging
|
10
|
+
.Python
|
11
|
+
build/
|
12
|
+
develop-eggs/
|
13
|
+
dist/
|
14
|
+
downloads/
|
15
|
+
eggs/
|
16
|
+
.eggs/
|
17
|
+
lib/
|
18
|
+
lib64/
|
19
|
+
parts/
|
20
|
+
sdist/
|
21
|
+
var/
|
22
|
+
wheels/
|
23
|
+
share/python-wheels/
|
24
|
+
*.egg-info/
|
25
|
+
.installed.cfg
|
26
|
+
*.egg
|
27
|
+
MANIFEST
|
28
|
+
|
29
|
+
# PyInstaller
|
30
|
+
# Usually these files are written by a python script from a template
|
31
|
+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
32
|
+
*.manifest
|
33
|
+
*.spec
|
34
|
+
|
35
|
+
# Installer logs
|
36
|
+
pip-log.txt
|
37
|
+
pip-delete-this-directory.txt
|
38
|
+
|
39
|
+
# Unit test / coverage reports
|
40
|
+
htmlcov/
|
41
|
+
.tox/
|
42
|
+
.nox/
|
43
|
+
.coverage
|
44
|
+
.coverage.*
|
45
|
+
.cache
|
46
|
+
nosetests.xml
|
47
|
+
coverage.xml
|
48
|
+
*.cover
|
49
|
+
*.py.cover
|
50
|
+
.hypothesis/
|
51
|
+
.pytest_cache/
|
52
|
+
cover/
|
53
|
+
|
54
|
+
# Translations
|
55
|
+
*.mo
|
56
|
+
*.pot
|
57
|
+
|
58
|
+
# Django stuff:
|
59
|
+
*.log
|
60
|
+
local_settings.py
|
61
|
+
db.sqlite3
|
62
|
+
db.sqlite3-journal
|
63
|
+
|
64
|
+
# Flask stuff:
|
65
|
+
instance/
|
66
|
+
.webassets-cache
|
67
|
+
|
68
|
+
# Scrapy stuff:
|
69
|
+
.scrapy
|
70
|
+
|
71
|
+
# Sphinx documentation
|
72
|
+
docs/_build/
|
73
|
+
|
74
|
+
# PyBuilder
|
75
|
+
.pybuilder/
|
76
|
+
target/
|
77
|
+
|
78
|
+
# Jupyter Notebook
|
79
|
+
.ipynb_checkpoints
|
80
|
+
*.ipynb
|
81
|
+
|
82
|
+
# IPython
|
83
|
+
profile_default/
|
84
|
+
ipython_config.py
|
85
|
+
|
86
|
+
# pyenv
|
87
|
+
# For a library or package, you might want to ignore these files since the code is
|
88
|
+
# intended to run in multiple environments; otherwise, check them in:
|
89
|
+
# .python-version
|
90
|
+
|
91
|
+
# pipenv
|
92
|
+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
93
|
+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
94
|
+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
95
|
+
# install all needed dependencies.
|
96
|
+
#Pipfile.lock
|
97
|
+
|
98
|
+
# UV
|
99
|
+
# Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
|
100
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
101
|
+
# commonly ignored for libraries.
|
102
|
+
#uv.lock
|
103
|
+
|
104
|
+
# poetry
|
105
|
+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
106
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
107
|
+
# commonly ignored for libraries.
|
108
|
+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
109
|
+
#poetry.lock
|
110
|
+
#poetry.toml
|
111
|
+
|
112
|
+
# pdm
|
113
|
+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
114
|
+
# pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
|
115
|
+
# https://pdm-project.org/en/latest/usage/project/#working-with-version-control
|
116
|
+
#pdm.lock
|
117
|
+
#pdm.toml
|
118
|
+
.pdm-python
|
119
|
+
.pdm-build/
|
120
|
+
|
121
|
+
# pixi
|
122
|
+
# Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
|
123
|
+
#pixi.lock
|
124
|
+
# Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
|
125
|
+
# in the .venv directory. It is recommended not to include this directory in version control.
|
126
|
+
.pixi
|
127
|
+
|
128
|
+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
129
|
+
__pypackages__/
|
130
|
+
|
131
|
+
# Celery stuff
|
132
|
+
celerybeat-schedule
|
133
|
+
celerybeat.pid
|
134
|
+
|
135
|
+
# SageMath parsed files
|
136
|
+
*.sage.py
|
137
|
+
|
138
|
+
# Environments
|
139
|
+
.env
|
140
|
+
.envrc
|
141
|
+
.venv
|
142
|
+
env/
|
143
|
+
venv/
|
144
|
+
ENV/
|
145
|
+
env.bak/
|
146
|
+
venv.bak/
|
147
|
+
!tests/env
|
148
|
+
|
149
|
+
# Spyder project settings
|
150
|
+
.spyderproject
|
151
|
+
.spyproject
|
152
|
+
|
153
|
+
# Rope project settings
|
154
|
+
.ropeproject
|
155
|
+
|
156
|
+
# mkdocs documentation
|
157
|
+
/site
|
158
|
+
|
159
|
+
# mypy
|
160
|
+
.mypy_cache/
|
161
|
+
.dmypy.json
|
162
|
+
dmypy.json
|
163
|
+
|
164
|
+
# Pyre type checker
|
165
|
+
.pyre/
|
166
|
+
|
167
|
+
# pytype static type analyzer
|
168
|
+
.pytype/
|
169
|
+
|
170
|
+
# Cython debug symbols
|
171
|
+
cython_debug/
|
172
|
+
|
173
|
+
# PyCharm
|
174
|
+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
175
|
+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
176
|
+
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
177
|
+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
178
|
+
#.idea/
|
179
|
+
|
180
|
+
# Abstra
|
181
|
+
# Abstra is an AI-powered process automation framework.
|
182
|
+
# Ignore directories containing user credentials, local state, and settings.
|
183
|
+
# Learn more at https://abstra.io/docs
|
184
|
+
.abstra/
|
185
|
+
|
186
|
+
# Visual Studio Code
|
187
|
+
# Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
|
188
|
+
# that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
|
189
|
+
# and can be added to the global gitignore or merged into this file. However, if you prefer,
|
190
|
+
# you could uncomment the following to ignore the entire vscode folder
|
191
|
+
# .vscode/
|
192
|
+
|
193
|
+
# Ruff stuff:
|
194
|
+
.ruff_cache/
|
195
|
+
|
196
|
+
# PyPI configuration file
|
197
|
+
.pypirc
|
198
|
+
|
199
|
+
# Cursor
|
200
|
+
# Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
|
201
|
+
# exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
|
202
|
+
# refer to https://docs.cursor.com/context/ignore-files
|
203
|
+
.cursorignore
|
204
|
+
.cursorindexingignore
|
205
|
+
|
206
|
+
# Marimo
|
207
|
+
marimo/_static/
|
208
|
+
marimo/_lsp/
|
209
|
+
__marimo__/
|
argmerge-0.0.0/LICENSE
ADDED
@@ -0,0 +1,21 @@
|
|
1
|
+
MIT License
|
2
|
+
|
3
|
+
Copyright (c) 2025 Dan Billmann
|
4
|
+
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
7
|
+
in the Software without restriction, including without limitation the rights
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
10
|
+
furnished to do so, subject to the following conditions:
|
11
|
+
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
13
|
+
copies or substantial portions of the Software.
|
14
|
+
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
21
|
+
SOFTWARE.
|
argmerge-0.0.0/PKG-INFO
ADDED
@@ -0,0 +1,101 @@
|
|
1
|
+
Metadata-Version: 2.4
|
2
|
+
Name: argmerge
|
3
|
+
Version: 0.0.0
|
4
|
+
Summary: Add your description here
|
5
|
+
Author-email: duck-bongos <billmannd@gmail.com>
|
6
|
+
License-File: LICENSE
|
7
|
+
Requires-Python: >=3.10
|
8
|
+
Requires-Dist: loguru>=0.7.3
|
9
|
+
Requires-Dist: mkdocs-material>=9.6.21
|
10
|
+
Requires-Dist: pydantic>=2.12.2
|
11
|
+
Requires-Dist: pyyaml>=6.0.3
|
12
|
+
Provides-Extra: documentation
|
13
|
+
Requires-Dist: mkdocs-autoapi>=0.4.1; extra == 'documentation'
|
14
|
+
Requires-Dist: mkdocs-landing>=0.0.8; extra == 'documentation'
|
15
|
+
Requires-Dist: mkdocs-terminal>=4.7.0; extra == 'documentation'
|
16
|
+
Requires-Dist: mkdocs>=1.6.1; extra == 'documentation'
|
17
|
+
Requires-Dist: mkdocstrings[python]>=0.30.1; extra == 'documentation'
|
18
|
+
Description-Content-Type: text/markdown
|
19
|
+
|
20
|
+
# `argmerge`
|
21
|
+
## Description
|
22
|
+
_Customize how program defaults and overrides from config files, environment variables, and CLI arguments "cross the threshold" into your program._
|
23
|
+
|
24
|
+
| | |
|
25
|
+
|---|---|
|
26
|
+
CI/CD |
|
27
|
+
Package | [](https://pypi.org/project/hatch-vcs/) |
|
28
|
+
Meta|[]
|
29
|
+
|
30
|
+
|
31
|
+

|
32
|
+

|
33
|
+
|
34
|
+
We retrieve each possible source of program arguments as Python dictionaries and then perform dictionary updates between each source before passing the final dictionary to the wrapped function. Effectively:
|
35
|
+
```py
|
36
|
+
source_1: dict
|
37
|
+
source_2: dict
|
38
|
+
|
39
|
+
source_1.update(source_2)
|
40
|
+
|
41
|
+
function(**source_1)
|
42
|
+
```
|
43
|
+
|
44
|
+
## Installation
|
45
|
+
We recommend using [`uv` for package management](http://docs.astral.sh/uv/).
|
46
|
+
```sh
|
47
|
+
uv add argmerge
|
48
|
+
```
|
49
|
+
|
50
|
+
If you're using pip you can run
|
51
|
+
```sh
|
52
|
+
pip install argmerge
|
53
|
+
```
|
54
|
+
|
55
|
+
## Usage
|
56
|
+
### Code Example
|
57
|
+
While designed for `main` functions, you can ddd the `@threshold` decorator to any program that interfaces with external variables or files.
|
58
|
+
```py
|
59
|
+
from argmerge import threshold
|
60
|
+
|
61
|
+
|
62
|
+
@threshold
|
63
|
+
def main(first: int, second: str, third: float = 0.0):
|
64
|
+
...
|
65
|
+
```
|
66
|
+
|
67
|
+
## Hierarchy
|
68
|
+
We determined the hierarchy based on (our perception of) developer experience. The intent is for higher priority sources to correspond to the quickest sources to change. For example, we perceive changing a CLI argument quicker than changing an environment variable - etc.
|
69
|
+
|
70
|
+
|
71
|
+
| Level | Rank |
|
72
|
+
| --- | --- |
|
73
|
+
| Developer-provided | 100 |
|
74
|
+
| CLI | 40 |
|
75
|
+
| Environment Variable | 30 |
|
76
|
+
| YAML File | 20 |
|
77
|
+
| JSON File | 10 |
|
78
|
+
| Python Function Default | 0 |
|
79
|
+
|
80
|
+
## FAQ
|
81
|
+
#### Why YAML over JSON?
|
82
|
+
We prioritized YAML above JSON is because we find it significantly easier to read because it has less "line noise". JSON contains copious amounts of brackets (`{`,`}`) and commas. These are the only two sources that can pass dictionaries in by default. Of course, passing in different Regular expressions for environment variables and CLI arguments could also capture dictionaries, if you want to figure that out.
|
83
|
+
|
84
|
+
## Planned Future Work
|
85
|
+
For specific bite-sized work, you can take a look at [our project's GitHub issues](https://github.com/duck-bongos/py-argmerge/issues). ⚠️ Caution - this project is new and issues may be under-specified ⚠️
|
86
|
+
|
87
|
+
#### Validation
|
88
|
+
We want users to be able to validate the input arguments to their program using a `PyDantic BaseModel`. This would slot in after we collect the arguments from all the different sources.
|
89
|
+
|
90
|
+
### Customizing `@threshold`
|
91
|
+
We provide ways to customize reading environment variables and CLI arguments with the `env_prefix` and `cli_pattern` parameters. If developers want to go a step further and pull values from external sources we haven't considered (like `.cfg` files), we would like to allow them to do so.
|
92
|
+
|
93
|
+
#### Databricks
|
94
|
+
Databricks offers a way to collect 'widgets' or 'secrets' in their notebooks at runtime and pass them into your program. [This is cool](https://docs.databricks.com/aws/en/notebooks/widgets). It also is higher-risk for not being able to exactly reproduce your workloads. This makes `@threshold` a very good candidate to merge arguments between the Databricks platform and other external sources. For example, though not recommended, it's possible to create widgets in a notebook that gets run in an asset bundle. Asset bundles can be run like CLI applications, which means you can pass arguments in from the CLI or the widgets.
|
95
|
+
|
96
|
+
#### Authentication
|
97
|
+
This is a tricky one, and we may not do it. Since we truly want to provide _everything_ a program needs to run, this would include any authentication keys - think Database access keys or application API keys. The way we'd retrieve keys varies between cloud platforms, as well as non-cloud platforms. What may make the most sense is for us to build some sort of plugin system that allows users to bring their own authentication
|
98
|
+
|
99
|
+
|
100
|
+
|
101
|
+
|
argmerge-0.0.0/README.md
ADDED
@@ -0,0 +1,82 @@
|
|
1
|
+
# `argmerge`
|
2
|
+
## Description
|
3
|
+
_Customize how program defaults and overrides from config files, environment variables, and CLI arguments "cross the threshold" into your program._
|
4
|
+
|
5
|
+
| | |
|
6
|
+
|---|---|
|
7
|
+
CI/CD |
|
8
|
+
Package | [](https://pypi.org/project/hatch-vcs/) |
|
9
|
+
Meta|[]
|
10
|
+
|
11
|
+
|
12
|
+

|
13
|
+

|
14
|
+
|
15
|
+
We retrieve each possible source of program arguments as Python dictionaries and then perform dictionary updates between each source before passing the final dictionary to the wrapped function. Effectively:
|
16
|
+
```py
|
17
|
+
source_1: dict
|
18
|
+
source_2: dict
|
19
|
+
|
20
|
+
source_1.update(source_2)
|
21
|
+
|
22
|
+
function(**source_1)
|
23
|
+
```
|
24
|
+
|
25
|
+
## Installation
|
26
|
+
We recommend using [`uv` for package management](http://docs.astral.sh/uv/).
|
27
|
+
```sh
|
28
|
+
uv add argmerge
|
29
|
+
```
|
30
|
+
|
31
|
+
If you're using pip you can run
|
32
|
+
```sh
|
33
|
+
pip install argmerge
|
34
|
+
```
|
35
|
+
|
36
|
+
## Usage
|
37
|
+
### Code Example
|
38
|
+
While designed for `main` functions, you can ddd the `@threshold` decorator to any program that interfaces with external variables or files.
|
39
|
+
```py
|
40
|
+
from argmerge import threshold
|
41
|
+
|
42
|
+
|
43
|
+
@threshold
|
44
|
+
def main(first: int, second: str, third: float = 0.0):
|
45
|
+
...
|
46
|
+
```
|
47
|
+
|
48
|
+
## Hierarchy
|
49
|
+
We determined the hierarchy based on (our perception of) developer experience. The intent is for higher priority sources to correspond to the quickest sources to change. For example, we perceive changing a CLI argument quicker than changing an environment variable - etc.
|
50
|
+
|
51
|
+
|
52
|
+
| Level | Rank |
|
53
|
+
| --- | --- |
|
54
|
+
| Developer-provided | 100 |
|
55
|
+
| CLI | 40 |
|
56
|
+
| Environment Variable | 30 |
|
57
|
+
| YAML File | 20 |
|
58
|
+
| JSON File | 10 |
|
59
|
+
| Python Function Default | 0 |
|
60
|
+
|
61
|
+
## FAQ
|
62
|
+
#### Why YAML over JSON?
|
63
|
+
We prioritized YAML above JSON is because we find it significantly easier to read because it has less "line noise". JSON contains copious amounts of brackets (`{`,`}`) and commas. These are the only two sources that can pass dictionaries in by default. Of course, passing in different Regular expressions for environment variables and CLI arguments could also capture dictionaries, if you want to figure that out.
|
64
|
+
|
65
|
+
## Planned Future Work
|
66
|
+
For specific bite-sized work, you can take a look at [our project's GitHub issues](https://github.com/duck-bongos/py-argmerge/issues). ⚠️ Caution - this project is new and issues may be under-specified ⚠️
|
67
|
+
|
68
|
+
#### Validation
|
69
|
+
We want users to be able to validate the input arguments to their program using a `PyDantic BaseModel`. This would slot in after we collect the arguments from all the different sources.
|
70
|
+
|
71
|
+
### Customizing `@threshold`
|
72
|
+
We provide ways to customize reading environment variables and CLI arguments with the `env_prefix` and `cli_pattern` parameters. If developers want to go a step further and pull values from external sources we haven't considered (like `.cfg` files), we would like to allow them to do so.
|
73
|
+
|
74
|
+
#### Databricks
|
75
|
+
Databricks offers a way to collect 'widgets' or 'secrets' in their notebooks at runtime and pass them into your program. [This is cool](https://docs.databricks.com/aws/en/notebooks/widgets). It also is higher-risk for not being able to exactly reproduce your workloads. This makes `@threshold` a very good candidate to merge arguments between the Databricks platform and other external sources. For example, though not recommended, it's possible to create widgets in a notebook that gets run in an asset bundle. Asset bundles can be run like CLI applications, which means you can pass arguments in from the CLI or the widgets.
|
76
|
+
|
77
|
+
#### Authentication
|
78
|
+
This is a tricky one, and we may not do it. Since we truly want to provide _everything_ a program needs to run, this would include any authentication keys - think Database access keys or application API keys. The way we'd retrieve keys varies between cloud platforms, as well as non-cloud platforms. What may make the most sense is for us to build some sort of plugin system that allows users to bring their own authentication
|
79
|
+
|
80
|
+
|
81
|
+
|
82
|
+
|