# RIFT
RIFT stands for - pa**R**ametrized **I**ntegration testing **F**ramework **T**ool.
It's an integration test framework that focuses its attention to the parametrization and standardization of test procedure.
[](https://anaconda.org/)
[](https://pypi.org/project/pip/)
[](https://github.com/astral-sh/ruff)
[](https://docs.pydantic.dev/latest/contributing/#badges)
[](https://python-poetry.org/)
## Installation
### Using mamba or conda (recommended)
```shell
mamba create -n riftenv
mamba activate riftenv
mamba install pit-rift
```
### Using pip
```bash
pip install pit-rift
```
## Usage
[How to create a test](#how-to-create-a-test) | [Documentation](doc/README_test_case.md)
```shell
rift <path_to_test_case> [-v VERBOSE_LEVEL] [-w WORK_DIR] [-i] [-h]
```
### Positional Argument
* `test_case`: Path to the test case (in ini format) to exec.
### Optional Arguments
* `-v VERBOSE_LEVEL`: Optional. Verbose level from 1 (CRITICAL) to 5 (DEBUG). Default is 4 (INFO).
* `-w WORK_DIR`: To change the test working directory. Default is ini_test_case_YYYYMMDDTHHmmss.
* `-i`: If the test case doesn't exist, create it
* `-h, --help`: Show this help message and exit.
### Usage Requirements
If we indicate with `<my_test_case>` a test case to execute, the following requirements must be satisfied:
1. The command `rift` must be executed in a directory which contains `tests`
2. The test implementation must be located in: `tests/<procedure_name>`,
where `<procedure_name>` is the value of `<my_test_case>[EXEC]test_procedure`
It's a good practice to save all test cases in a directory called `test_cases`
## How to create a test
To create a test case **my_test_case**, run the commands:
```shell
rift test_cases/my_test_case.ini -i
```
After the execution, your working directory will appear like this:
```shell
CWD/
├── my_test_case.ini_20240105T165240
│ ├── log
│ │ ├── my_test_case.ini
│ │ ├── pid
│ │ └── test.log
│ ├── out
│ └── work
├── my_test_case.ini
└── tests
└── my_test_case
└── main.sh
```
Expected output:
```shell
(base) [am09320@juno CMCC_local]$ rift test_cases/my_test_case.ini -i
[2024-01-05T17:08:30Z] - INFO - mock.create_test: Init test case: test_cases/my_test_case.ini
[2024-01-05T17:08:30Z] - INFO - mock.init_test_procedure: Mkdir procedure: /work/opa/am09320/dev/DevOpsEnv/CMCC_local/tests/mock_test
[2024-01-05T17:08:30Z] - INFO - mock.init_test_procedure: Copy /work/opa/am09320/dev/DevOpsEnv/dev_refactoring/conf/main.sh to /work/opa/am09320/dev/DevOpsEnv/CMCC_local/tests/mock_test
[2024-01-05T17:08:30Z] - INFO - mock.init_test_case: Mkdir test_cases
[2024-01-05T17:08:30Z] - INFO - mock.init_test_case: Copy /work/opa/am09320/dev/DevOpsEnv/dev_refactoring/conf/test_case.ini as test_cases/my_test_case.ini
[2024-01-05T17:08:30Z] - INFO - rift.main: Loading test case: test_cases/my_test_case.ini
...
[2024-01-05T17:08:30Z] - INFO - scheduler.exec: EXECUTION START
INFO Loading modules
INFO Starting test case
Hello World!
Variable declared into test_case: This is a test
[2024-01-05T17:08:30Z] - INFO - scheduler.exec: EXECUTION_DONE
```
Once the test has been created, the parameter `-i` can be omitted
### Long runs
If the running time of a test is too long (due to the running time or the waiting time of a job),
it's possible to exec rift in background using `nohup`:
```shell
nohup rift test_cases/my_test_case.ini &> my_test_case.log &
```
---
## Authors
* **Antonio mariani** - antonio.mariani@cmcc.it
### Contributors
- **Massimiliano Drudi** - massimiliano.drudi@cmcc.it
---
## References
- What is DevOps?, Web article, https://opensource.com/resources/devops?src=devops_resource_menu1
- Is there a reproducibility crisis in Science?, Nature Video, 2016, https://www.nature.com/articles/d41586-019-00067-3
- Keyes DE, McInnes LC, Woodward C, et al. Multiphysics simulations: Challenges and opportunities. The International
Journal of High Performance Computing Applications. 2013;27(1):4-83. https://doi.org/10.1177/1094342012468181
- Theorists and experimentalists must join forces, Nature Editorial,
2021, https://www.nature.com/articles/s43588-021-00082-3
- But is the code (re)usable?, Nature Editorial, 2021, https://www.nature.com/articles/s43588-021-00109-9
- Zebula Sampedro, Aaron Holt, and Thomas Hauser. 2018. Continuous Integration and Delivery for HPC: Using Singularity
and Jenkins. In Proceedings of the Practice and Experience on Advanced Research Computing (PEARC '18). Association for
Computing Machinery, New York, NY, USA, Article 6, 1–6. https://doi.org/10.1145/3219104.3219147
- Dong H. Ahn, Allison H. Baker, Michael Bentley, Ian Briggs, Ganesh Gopalakrishnan, Dorit M. Hammerling, Ignacio
Laguna, Gregory L. Lee, Daniel J. Milroy, and Mariana Vertenstein. 2021. Keeping science on keel when software moves.
Commun. ACM 64, 2 (February 2021), 66–74. https://doi.org/10.1145/3382037
- National Academies of Sciences, Engineering, and Medicine. 2019. Reproducibility and Replicability in Science.
Washington, DC: The National Academies Press. https://doi.org/10.17226/25303.
- Geyer, B., Ludwig, T. & von Storch, H. Limits of reproducibility and hydrodynamic noise in atmospheric regional
modelling. Commun Earth Environ 2, 17 (2021). https://doi.org/10.1038/s43247-020-00085-4
# RIFT Framework Documentation
## Introduction
The RIFT framework, puts its focus in the procedure re-usability,
providing the necessary execution information via parameters.
It's composed by:
* **Test case**: It's a configuration file in .ini format which contains the necessary information for executing a test.
Each test case, represents a well specific scenario that must be tested using a general procedure.
* **Test procedure**: Parameterized code that runs the test with the parameters and environment provided by a test case
## Test case
### Template
Here is a template that can be used as base to build your own test case:
```ini
[Environment]
MY_VAR = value1
...
MY_VARX = Another value
[Exec]
test_procedure = mock_test_procedure
;write as module1 module2 ... moduleX -> automatic loaded before to call the test procedure
modules =
;if defined, the conda environment is automatic loaded before to call the test procedure
conda_env =
;the git sections are optionals - it is possible to declare as much section as you want
[GIT_REPO1]
name = REPO1
url = SSH_GIT_URL
; branch or tag to download - mandatory
branch = GIT_BRANCH
[GIT_REPOX]
;cloned as CMCC_local/<name>
name = REPOX
url = SSH_GIT_URL
; branch or tag to download - mandatory
branch = GIT_BRANCH
```
### Example
Here is a real example of a working test case (from [quick-start example](../README.md#quick-start)):
```shell
[Environment]
MY_VAR = This is a test
MY_VAR2 = Another custom variable
[Exec]
test_procedure = mock_test_procedure
# no modules to load
modules =
# no conda env to load
conda_env =
```
### Section Environment
In the environment section:
* declaring all variables needed to exec the test
* the variable name is case-sensitive: `VAR != var`
* all variables will be automatically exported by the test framework before to run the test procedure
* no limit in the number of variables that ca be declared
* a variable can refer to another variable declared previously into the same file using the bash syntax:
```
var1 = MY_VALUE
;set var2 as MY_VALUE_extend
var2 = ${var1}_extended
```
### Section Exec
In this section, is reported some information needed for the test execution:
* **test_procedure**: name of the directory in `CMCC_local/tests` which contains the main.sh to start the test
* **modules**: list of module name that will be loaded using te command `module load` before to run the test procedure (ignored if empty)
* **conda_env**: name of the conda env to load before to run the test procedure (ignored if empty)
## Test Procedure
### Definition
A test procedure is a collection of parametrized procedures which are in charge to exec the test.
It's composed by:
* **main.sh**: it's the starting point called by the test framework
* any other executable script necessary for the test execution: **the test procedure path will be added to the PATH**, this means that it is possible to use into the test case any script that the test needs
### Global Environment
Here is a list of global variables exported by the test framework that can be used in the test implementation:
- **SOURCE_DIR**: The parent directory of CMCC_local
- **TEST_DIR**: The test procedure dir: `CMCC_local/tests/<test_case>`
- **LOG_DIR**: `<test_case>_YYYYMMDDTHHmmss/log`
- **WORK_DIR**: `<test_case>_YYYYMMDDTHHmmss/work`
- **DATA_DIR**: `<test_case>_YYYYMMDDTHHmmss/data`
- **OUT_DIR**: `<test_case>_YYYYMMDDTHHmmss/out`
- **STATUS_DIR**: `<test_case>_YYYYMMDDTHHmmss/status`
### Global Function
The bash libraries introduced with old versions of rift,
are still available, but they will be removed in the next releases.
The libraries will print a warning message to alert the users.
Currently, the test framework, provides two type of libraries:
* [Logging](#logging)
* [Submission](#submission)
#### Logging
It is a bash implementation of the python logging library [[1]](#1-logging-facility-for-python):
* `logger::debug`
* `logger::info`
* `logger::warning`
* `logger::error`
* `logger::critical`
For each function, the printed format is:
```shell
[YYYY-MM-DDTHH:mm:ssZ] - <LEVEL> - <FUNC_NAME>: <MSG>
```
where LEVEL is: DEBUG, INFO, WARNING, ERROR, CRITICAL
#### Submission
A function is available to submit a job to LSF or SLURM with a general interface.
```shell
Usage: exec_task <cmd> [OPTIONS]
OPTIONS
-m, --mem <memory> Sets a memory limit for all the processes that belong to the job.
-r, --runtime <runtime> Sets the runtime limit of the job.
-q, --queue Submits the job to specified queue.
-j, --jobname <jobname> Assigns the specified name to the job
-w, --wait Submits a job and waits for the job to complete. Sends job status messages to the terminal
-l, --log <log> Path of the directory where to write LSF/SLURM log files
-h, --help Show this help message and exit
```
As an alternative, it is possible to pass some parameter directly from variables declared into the test case:
* **SUBMIT_MEM_LIMIT**: Sets a memory limit for all the processes that belong to the job.
* **SUBMIT_RUN_TIME**: Sets the runtime limit of the job.
* **SUBMIT_QUEUE**: Submit the job to specified queue.
* **SUBMIT_LOG_DIR**: Path of the directory where to write LSF/SLURM log files
## Test Execution
If we indicate with `<cmcc_local>` the path of CMCC_local which contains the test,
to exec a test `<my_test_case>`exec the commands:
```shell
cd <cmcc_local>
rift test_cases/<my_test_case>.ini
```
## Reference
### R1.
Logging facility for Python, [direct link](https://docs.python.org/3/library/logging.html)
Raw data
{
"_id": null,
"home_page": null,
"name": "pit-rift",
"maintainer": null,
"docs_url": null,
"requires_python": "<4.0,>=3.10",
"maintainer_email": null,
"keywords": "test, intragration testing, CI/CD, devops, test suite",
"author": "Antonio Mariani",
"author_email": "antonio.mariani@cmcc.it",
"download_url": "https://files.pythonhosted.org/packages/93/da/8a7aee6d23af15fac509dc3dd3c213373cf4123b5cc5d878bde775f622de/pit_rift-0.1.5.tar.gz",
"platform": null,
"description": "# RIFT\n\nRIFT stands for - pa**R**ametrized **I**ntegration testing **F**ramework **T**ool.\nIt's an integration test framework that focuses its attention to the parametrization and standardization of test procedure.\n\n\n\n[](https://anaconda.org/)\n[](https://pypi.org/project/pip/)\n[](https://github.com/astral-sh/ruff)\n[](https://docs.pydantic.dev/latest/contributing/#badges)\n[](https://python-poetry.org/)\n\n\n## Installation\n\n### Using mamba or conda (recommended)\n\n```shell\nmamba create -n riftenv\nmamba activate riftenv\nmamba install pit-rift\n```\n\n### Using pip\n\n```bash\npip install pit-rift\n```\n\n## Usage\n\n[How to create a test](#how-to-create-a-test) | [Documentation](doc/README_test_case.md)\n\n```shell\nrift <path_to_test_case> [-v VERBOSE_LEVEL] [-w WORK_DIR] [-i] [-h]\n```\n### Positional Argument\n\n* `test_case`: Path to the test case (in ini format) to exec.\n\n### Optional Arguments\n\n* `-v VERBOSE_LEVEL`: Optional. Verbose level from 1 (CRITICAL) to 5 (DEBUG). Default is 4 (INFO).\n* `-w WORK_DIR`: To change the test working directory. Default is ini_test_case_YYYYMMDDTHHmmss.\n* `-i`: If the test case doesn't exist, create it\n* `-h, --help`: Show this help message and exit.\n\n\n### Usage Requirements\n\nIf we indicate with `<my_test_case>` a test case to execute, the following requirements must be satisfied:\n\n1. The command `rift` must be executed in a directory which contains `tests`\n2. The test implementation must be located in: `tests/<procedure_name>`, \n where `<procedure_name>` is the value of `<my_test_case>[EXEC]test_procedure`\n\nIt's a good practice to save all test cases in a directory called `test_cases`\n\n## How to create a test\n\nTo create a test case **my_test_case**, run the commands:\n\n```shell\nrift test_cases/my_test_case.ini -i\n```\n\nAfter the execution, your working directory will appear like this:\n\n```shell\nCWD/\n\u251c\u2500\u2500 my_test_case.ini_20240105T165240\n\u2502 \u251c\u2500\u2500 log\n\u2502 \u2502 \u251c\u2500\u2500 my_test_case.ini\n\u2502 \u2502 \u251c\u2500\u2500 pid\n\u2502 \u2502 \u2514\u2500\u2500 test.log\n\u2502 \u251c\u2500\u2500 out\n\u2502 \u2514\u2500\u2500 work\n\u251c\u2500\u2500 my_test_case.ini\n\u2514\u2500\u2500 tests\n \u2514\u2500\u2500 my_test_case\n \u2514\u2500\u2500 main.sh\n```\n\nExpected output:\n\n```shell\n(base) [am09320@juno CMCC_local]$ rift test_cases/my_test_case.ini -i\n[2024-01-05T17:08:30Z] - INFO - mock.create_test: Init test case: test_cases/my_test_case.ini\n[2024-01-05T17:08:30Z] - INFO - mock.init_test_procedure: Mkdir procedure: /work/opa/am09320/dev/DevOpsEnv/CMCC_local/tests/mock_test\n[2024-01-05T17:08:30Z] - INFO - mock.init_test_procedure: Copy /work/opa/am09320/dev/DevOpsEnv/dev_refactoring/conf/main.sh to /work/opa/am09320/dev/DevOpsEnv/CMCC_local/tests/mock_test\n[2024-01-05T17:08:30Z] - INFO - mock.init_test_case: Mkdir test_cases\n[2024-01-05T17:08:30Z] - INFO - mock.init_test_case: Copy /work/opa/am09320/dev/DevOpsEnv/dev_refactoring/conf/test_case.ini as test_cases/my_test_case.ini\n[2024-01-05T17:08:30Z] - INFO - rift.main: Loading test case: test_cases/my_test_case.ini\n...\n[2024-01-05T17:08:30Z] - INFO - scheduler.exec: EXECUTION START\nINFO Loading modules\n\nINFO Starting test case\nHello World!\nVariable declared into test_case: This is a test\n[2024-01-05T17:08:30Z] - INFO - scheduler.exec: EXECUTION_DONE\n```\n\nOnce the test has been created, the parameter `-i` can be omitted\n\n### Long runs\nIf the running time of a test is too long (due to the running time or the waiting time of a job),\nit's possible to exec rift in background using `nohup`:\n\n```shell\nnohup rift test_cases/my_test_case.ini &> my_test_case.log &\n```\n\n---\n## Authors\n\n* **Antonio mariani** - antonio.mariani@cmcc.it\n\n### Contributors\n\n- **Massimiliano Drudi** - massimiliano.drudi@cmcc.it\n\n---\n## References\n\n- What is DevOps?, Web article, https://opensource.com/resources/devops?src=devops_resource_menu1\n- Is there a reproducibility crisis in Science?, Nature Video, 2016, https://www.nature.com/articles/d41586-019-00067-3\n- Keyes DE, McInnes LC, Woodward C, et al. Multiphysics simulations: Challenges and opportunities. The International\n Journal of High Performance Computing Applications. 2013;27(1):4-83. https://doi.org/10.1177/1094342012468181\n- Theorists and experimentalists must join forces, Nature Editorial,\n 2021, https://www.nature.com/articles/s43588-021-00082-3\n- But is the code (re)usable?, Nature Editorial, 2021, https://www.nature.com/articles/s43588-021-00109-9\n- Zebula Sampedro, Aaron Holt, and Thomas Hauser. 2018. Continuous Integration and Delivery for HPC: Using Singularity\n and Jenkins. In Proceedings of the Practice and Experience on Advanced Research Computing (PEARC '18). Association for\n Computing Machinery, New York, NY, USA, Article 6, 1\u20136. https://doi.org/10.1145/3219104.3219147\n- Dong H. Ahn, Allison H. Baker, Michael Bentley, Ian Briggs, Ganesh Gopalakrishnan, Dorit M. Hammerling, Ignacio\n Laguna, Gregory L. Lee, Daniel J. Milroy, and Mariana Vertenstein. 2021. Keeping science on keel when software moves.\n Commun. ACM 64, 2 (February 2021), 66\u201374. https://doi.org/10.1145/3382037\n- National Academies of Sciences, Engineering, and Medicine. 2019. Reproducibility and Replicability in Science.\n Washington, DC: The National Academies Press. https://doi.org/10.17226/25303.\n- Geyer, B., Ludwig, T. & von Storch, H. Limits of reproducibility and hydrodynamic noise in atmospheric regional\n modelling. Commun Earth Environ 2, 17 (2021). https://doi.org/10.1038/s43247-020-00085-4\n\n# RIFT Framework Documentation\n\n## Introduction\n\nThe RIFT framework, puts its focus in the procedure re-usability,\nproviding the necessary execution information via parameters.\n\nIt's composed by:\n\n* **Test case**: It's a configuration file in .ini format which contains the necessary information for executing a test.\n Each test case, represents a well specific scenario that must be tested using a general procedure.\n* **Test procedure**: Parameterized code that runs the test with the parameters and environment provided by a test case\n\n## Test case\n\n### Template\n\nHere is a template that can be used as base to build your own test case:\n\n```ini\n[Environment]\n\nMY_VAR = value1\n...\nMY_VARX = Another value\n\n[Exec]\ntest_procedure = mock_test_procedure\n;write as module1 module2 ... moduleX -> automatic loaded before to call the test procedure\nmodules =\n;if defined, the conda environment is automatic loaded before to call the test procedure\nconda_env =\n\n;the git sections are optionals - it is possible to declare as much section as you want\n[GIT_REPO1]\nname = REPO1\nurl = SSH_GIT_URL\n; branch or tag to download - mandatory\nbranch = GIT_BRANCH\n\n[GIT_REPOX]\n;cloned as CMCC_local/<name>\nname = REPOX\nurl = SSH_GIT_URL\n; branch or tag to download - mandatory\nbranch = GIT_BRANCH\n```\n\n### Example\n\nHere is a real example of a working test case (from [quick-start example](../README.md#quick-start)):\n\n```shell\n[Environment]\n\nMY_VAR = This is a test\nMY_VAR2 = Another custom variable\n\n\n[Exec]\n\ntest_procedure = mock_test_procedure\n# no modules to load\nmodules =\n# no conda env to load\nconda_env =\n```\n\n### Section Environment\n\nIn the environment section:\n\n* declaring all variables needed to exec the test\n* the variable name is case-sensitive: `VAR != var`\n* all variables will be automatically exported by the test framework before to run the test procedure\n* no limit in the number of variables that ca be declared\n* a variable can refer to another variable declared previously into the same file using the bash syntax: \n```\nvar1 = MY_VALUE\n;set var2 as MY_VALUE_extend\nvar2 = ${var1}_extended\n```\n\n### Section Exec\nIn this section, is reported some information needed for the test execution:\n\n* **test_procedure**: name of the directory in `CMCC_local/tests` which contains the main.sh to start the test\n* **modules**: list of module name that will be loaded using te command `module load` before to run the test procedure (ignored if empty) \n* **conda_env**: name of the conda env to load before to run the test procedure (ignored if empty)\n\n\n## Test Procedure\n### Definition\n\nA test procedure is a collection of parametrized procedures which are in charge to exec the test. \nIt's composed by:\n\n* **main.sh**: it's the starting point called by the test framework\n* any other executable script necessary for the test execution: **the test procedure path will be added to the PATH**, this means that it is possible to use into the test case any script that the test needs\n\n\n### Global Environment\nHere is a list of global variables exported by the test framework that can be used in the test implementation:\n\n- **SOURCE_DIR**: The parent directory of CMCC_local\n- **TEST_DIR**: The test procedure dir: `CMCC_local/tests/<test_case>`\n- **LOG_DIR**: `<test_case>_YYYYMMDDTHHmmss/log`\n- **WORK_DIR**: `<test_case>_YYYYMMDDTHHmmss/work`\n- **DATA_DIR**: `<test_case>_YYYYMMDDTHHmmss/data`\n- **OUT_DIR**: `<test_case>_YYYYMMDDTHHmmss/out`\n- **STATUS_DIR**: `<test_case>_YYYYMMDDTHHmmss/status`\n\n### Global Function\n\nThe bash libraries introduced with old versions of rift,\nare still available, but they will be removed in the next releases.\nThe libraries will print a warning message to alert the users.\n\nCurrently, the test framework, provides two type of libraries:\n\n* [Logging](#logging)\n* [Submission](#submission)\n\n#### Logging\nIt is a bash implementation of the python logging library [[1]](#1-logging-facility-for-python):\n\n* `logger::debug`\n* `logger::info`\n* `logger::warning`\n* `logger::error`\n* `logger::critical`\n\nFor each function, the printed format is:\n\n```shell\n[YYYY-MM-DDTHH:mm:ssZ] - <LEVEL> - <FUNC_NAME>: <MSG>\n```\nwhere LEVEL is: DEBUG, INFO, WARNING, ERROR, CRITICAL\n\n#### Submission\n\nA function is available to submit a job to LSF or SLURM with a general interface.\n\n```shell\nUsage: exec_task <cmd> [OPTIONS]\n\nOPTIONS\n -m, --mem <memory> Sets a memory limit for all the processes that belong to the job.\n -r, --runtime <runtime> Sets the runtime limit of the job.\n -q, --queue Submits the job to specified queue.\n -j, --jobname <jobname> Assigns the specified name to the job\n -w, --wait Submits a job and waits for the job to complete. Sends job status messages to the terminal\n -l, --log <log> Path of the directory where to write LSF/SLURM log files\n -h, --help Show this help message and exit\n```\n\nAs an alternative, it is possible to pass some parameter directly from variables declared into the test case:\n\n* **SUBMIT_MEM_LIMIT**: Sets a memory limit for all the processes that belong to the job.\n* **SUBMIT_RUN_TIME**: Sets the runtime limit of the job.\n* **SUBMIT_QUEUE**: Submit the job to specified queue.\n* **SUBMIT_LOG_DIR**: Path of the directory where to write LSF/SLURM log files\n\n## Test Execution\n\nIf we indicate with `<cmcc_local>` the path of CMCC_local which contains the test,\nto exec a test `<my_test_case>`exec the commands:\n\n```shell\ncd <cmcc_local>\nrift test_cases/<my_test_case>.ini\n```\n\n\n## Reference\n\n### R1. \nLogging facility for Python, [direct link](https://docs.python.org/3/library/logging.html)\n",
"bugtrack_url": null,
"license": null,
"summary": "Parametrized Integration Testing framework Tool",
"version": "0.1.5",
"project_urls": null,
"split_keywords": [
"test",
" intragration testing",
" ci/cd",
" devops",
" test suite"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "54df13fbacd8cb02f12280e0701efd5deb0a1163ccd3fd9ee2f4ed357d7273c4",
"md5": "4e4c9f60ee29cc13b6459e9349945660",
"sha256": "23a4362ed6b88fea33cc909e1084c33e598c7730296b75cacf6b1eac2ab927dc"
},
"downloads": -1,
"filename": "pit_rift-0.1.5-py3-none-any.whl",
"has_sig": false,
"md5_digest": "4e4c9f60ee29cc13b6459e9349945660",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "<4.0,>=3.10",
"size": 40774,
"upload_time": "2024-09-20T12:15:05",
"upload_time_iso_8601": "2024-09-20T12:15:05.930962Z",
"url": "https://files.pythonhosted.org/packages/54/df/13fbacd8cb02f12280e0701efd5deb0a1163ccd3fd9ee2f4ed357d7273c4/pit_rift-0.1.5-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "93da8a7aee6d23af15fac509dc3dd3c213373cf4123b5cc5d878bde775f622de",
"md5": "40a3f487c26a69d6d22c09f4dae35643",
"sha256": "b5fb0f4e1d798952887ae9cf351c4a2c677678363049f7ba1b7fb38c4a391179"
},
"downloads": -1,
"filename": "pit_rift-0.1.5.tar.gz",
"has_sig": false,
"md5_digest": "40a3f487c26a69d6d22c09f4dae35643",
"packagetype": "sdist",
"python_version": "source",
"requires_python": "<4.0,>=3.10",
"size": 35113,
"upload_time": "2024-09-20T12:15:07",
"upload_time_iso_8601": "2024-09-20T12:15:07.488654Z",
"url": "https://files.pythonhosted.org/packages/93/da/8a7aee6d23af15fac509dc3dd3c213373cf4123b5cc5d878bde775f622de/pit_rift-0.1.5.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-09-20 12:15:07",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "pit-rift"
}
JSON