semvec/pypi-packages huggingface dataset:
wipeout 0.0.1
Tooling for debugging later
Requires Python: >=3.10

# Wipeout 🌊

*Savable/debuggable exceptions*

Note: this project contains code taken from the awesome, but no longer maintained [pydump](https://github.com/elifiner/pydump)

## Motivation

Ever wish you could just jump into debugging an error that happened in production?

Wipeout will let you do that (with a few limitations at the moment)

It overrides the python system exception hook (the thing that happens when python crashes out due to an unhandled error) so that before exiting, a rerunnable traceback will be saved.

Wipeout also makes use of the great library *fsspec* so that you can save/load debug sessions to a variety of storage options (local, s3, azure blob, ssh, etc etc).

## How to

### Install

```bash
pip install wipeout
```

### Use to store and load exceptions

Here's a simple example to save to a static file:

```python
import wipeout

wipeout.install(lambda: "~/coolfile.wipeout")
```

After that, if the code hits an error, it'll save a debug session to that location, which can later be triggered with:

```bash
python -m wipeout.load --file ~/coolfile.wipeout
```

The above command will open up a postmortem session in your debugger of choice (based on your `PYTHONBREAKPOINT` environment variable) where your error happened.

You might want to include a date or something so that multiple errors don't overwrite each other.

```python
from datetime import datetime

import wipeout

def filename_function():
  date_string = datetime.now().strftime("%Y%m%d%H%S%f")
  return f"~/cool_{date_string}.wipeout"

wipeout.install(filename_function)
```

And you can pass in storage options plus an fsspec prefix if you wanted to save in the cloud (see fsspec for more details):

```python
from datetime import datetime

import wipeout

def filename_function():
  date_string = datetime.now().strftime("%Y%m%d%H%S%f")
  return f"abfs://someplace/cool_{date_string}.wipeout"

wipeout.install(filename_function, storage_options={"account_name": "blobstore", "anon": False})
```


### Run mode

Wipeout also has a "run mode" which is a quick command to support running a python script as normal, but jumping into a debug session if an error is raised:

```bash
python -m wipeout.run rad/python/script.py
```
crimson-pymongo-bridge 0.1.1
Your package description.
Requires Python: >=3.9

**Template README.md**\
This file is from the [template repository](https://github.com/crimson206/template/blob/main/README.md).
Rewrite it for your own package.

## Python Package Setup

### Setup Base

To install required pip modules for `generate_toml.py`, run
``` bash
source scripts/setup_base.sh
```

### User Setup

- go to `generate_toml.py` file, and complete the setup in the `User Setup` session.

```python
options = Options(
    # Will you use the discussion session in your repo?
    discussion=False
)

# Define the general information of your package
kwargs = Kwargs(
    name_space="None",
    module_name="None",
    description="None",
)
```

If you wrote all the information, run
```
python generate_toml.py
```

#### Template

If you want to understand the generation process, check the `template` variable in `generate_toml.py`.

### Setup Env

#### Prerequisite

Finish [User Setup](#user-setup) first.
Of course, conda command must be available.

#### Setup Env

Run
``` bash
source scripts/setup_env.sh
```

steps
- create an conda environment named as your $MODULE_NAME
- activate the environment.
- install requirements.txt

#### Generate Private Env
Generate a private repository in this repo.
I recommend you to write all the unstructured codes in this repo.

``` bash
source scripts/generate_dev_repo.sh
```

It will ask you the name of your repo, and then, generate a repo named f'{your_repo_name}-dev'.

**Usage Tip**

If you wrote your codes in a wrong branch,
- backup the files to the dev repo
- remove changes in your main(not main branch) repo
- move to your correct branch
- place back the backup codes


## Workflows

I currently setup test and release workflows.

**Test**

If you make a PR with the patterns [ main, develop, 'release/*', 'feature/*' ],

It will perform your unittest in ["3.9", "3.10", "3.11"]

**Release**

required secret : PYPI_API_TOKEN

I usually make PRs only when I start release branches.
release workflow is not conducted automatically. If you think your branch is ready to be published, 

- go to https://github.com/{github_id}/{repo_name}/actions/workflows/release.yaml
- find the button, 'Run workflow'
- select the branch to publish. In my case, release/x.x.x