semvec/pypi-packages huggingface dataset:
ht-serve 0.0.3
A secure HTTPS live reload server for front-end prototyping and dashboard development
License: MIT
Requires Python: >=3.8
Keywords: https, tls, live-reload, webdev, dashboard, frontend, hot-reload, dev-server

# HT-Serve

[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)

**HT-Serve** is a secure HTTPS file server with live reload support, built for UI/dashboard prototyping. It enables frontend developers to test real-time changes under TLS with zero configuration, WebSocket-triggered reloads, and a CLI interface for orchestration.

---

## 🔧 Features

- 🔒 Auto HTTPS via self-signed certificates (or use custom certs)
- 🔁 WebSocket-based live reload on file changes
- 🧩 Automatic HTML injection of live-reload script
- 🧪 Built-in test UI (`ht-serve reset-demo`)
- 🔍 Health check endpoint at `/healthz`
- 🧠 CLI interface with `serve`, `check`, and `reset-demo`
- 🧾 Production-grade logging and debug mode (`HT_DEBUG=1`)

---

## 📦 Installation

```bash
pip install .
```

---

## 🚀 Usage

Launch the development server:

```bash
ht-serve serve --open-browser
```

Check if HTTPS/WebSocket ports are available:

```bash
ht-serve check
```

Reset and regenerate a demo UI site:

```bash
ht-serve reset-demo
```

---

## ⚙️ Environment Variables

| Variable         | Description                                                     |
|------------------|-----------------------------------------------------------------|
| `DASH_CERT_PATH` | Full path to the HTTPS certificate (`.pem`)                    |
| `DASH_KEY_PATH`  | Full path to the HTTPS private key (`.key`)                    |
| `DASH_PORT`      | Port to serve HTTPS on (default: `443`; fallback: `8443`)      |
| `HT_DEBUG`       | Set to `1` to enable verbose logging and file event tracking   |
| `HT_FORCE_CERT`  | Set to `1` to regenerate the TLS cert/key on next launch       |

---

## 📁 Directory Structure

```
HT-Serve/
├── ht_serve/
│   ├── cli.py               # Typer-based CLI commands
│   ├── server.py            # Core HTTPS + WebSocket server logic
│   ├── templates/
│   │   └── inject.js        # Injected live-reload script
│   └── testsite/            # Sample demo UI assets
├── pyproject.toml
├── requirements.txt
├── setup.py
└── README.md
```

---

## 🪪 License

MIT © [HermiTech Labs](https://github.com/HermiTech-LLC)
octodns-gcore 1.0.0
Gcore DNS v2 API provider for octoDNS
License: MIT
Requires Python: >=3.9

## Gcore DNS v2 API provider for octoDNS

An [octoDNS](https://github.com/octodns/octodns/) provider that targets [Gcore DNS](https://gcore.com/dns/).

### Installation

#### Command line

```
pip install octodns-gcore
```

#### requirements.txt/setup.py

Pinning specific versions or SHAs is recommended to avoid unplanned upgrades.

##### Versions

```
# Start with the latest versions and don't just copy what's here
octodns==0.9.14
octodns-gcore==0.0.1
```

##### SHAs

```
# Start with the latest/specific versions and don't just copy what's here
-e git+https://git@github.com/octodns/octodns.git@9da19749e28f68407a1c246dfdf65663cdc1c422#egg=octodns
-e git+https://git@github.com/octodns/octodns-gcore.git@ec9661f8b335241ae4746eea467a8509205e6a30#egg=octodns_gcore
```

### Configuration

#### GCoreProvider

```yaml
providers:
  gcore:
    class: octodns_gcore.GCoreProvider
    # Your API key
    token: env/GCORE_TOKEN
    token_type: APIKey
    # or login + password
    #login: env/GCORE_LOGIN
    #password: env/GCORE_PASSWORD
    #auth_url: https://api.gcore.com/iam
    #url: https://api.gcore.com/dns/v2
    #records_per_response: 1
```

### Support Information

#### Records

Supports A, AAAA, ALIAS (CNAME flattening), NS, MX, TXT, SRV, CNAME, and PTR.
CNAME flattening resolves both A and AAAA records and inherits the upstream TTL.

#### Root NS Records
The GCore provider supports full root NS record management.

#### Dynamic

Supports dynamic records.

### Development

See the [/script/](/script/) directory for some tools to help with the development process. They generally follow the [Script to rule them all](https://github.com/github/scripts-to-rule-them-all) pattern. Most useful is `./script/bootstrap` which will create a venv and install both the runtime and development related requirements. It will also hook up a pre-commit hook that covers most of what's run by CI.