semvec/pypi-packages huggingface dataset:
django-json-editor-field 0.4.2
JSON Editor support for Django JSON Fields
Requires Python: >=3.11

# Django JSON Editor Field

The Django JSON Editor field enhances [Djangos JSON
Field](https://docs.djangoproject.com/en/stable/ref/models/fields/#django.db.models.JSONField)
add adds a [json-editor](https://github.com/json-editor/json-editor) on top.
You can use a JSON Schema to describe a form for the underlying JSON field. The
input is then stored as JSON.

# Usage

Add `django_json_editor_field` to your [INSTALLED_APPS](https://docs.djangoproject.com/en/stable/ref/settings/#std-setting-INSTALLED_APPS).

Use the field in your model:

```python
from django_json_editor_field.fields import JSONEditorField

schema = {
        "title": "My JSON Array of Objects",
        "type": "array",
        "format": "table",
        "items": {
            "type": "object",
            "properties": {
                "name": {
                    "type": "string",
                },
                "start": {
                    "type": "string",
                    "format": "date",
                },
                "end": {
                    "type": "string",
                    "format": "date",
                }
            }
        }
}

data = JSONEditorField(schema=schema)
```


[json-editor](https://github.com/json-editor/json-editor?tab=readme-ov-file#options) has some options. You can set
them using the `options` argument to the JSONEditorField.

```
options = {
    "theme": "bootstrap4",
    "disable_collapse": True,
}
schema = {
    ...
}
data = JSONEditorField(schema=schema, options=options)
```

Internally, the schema gets added to the `schema` attribute of the options and only the `options` object gets passed on
to the json-editor. This means you can also define the `schema` as part of the options directly.
pyfastlru 1.0.3
Python implementation of a thread-safe LRU cache.
Requires Python: >=3.12

# pyfastlru v. 1.0

**Python implementation of a thread-safe LRU cache.**

Features: thread safety, statistics, familiar interface.

The MIT License (MIT). Copyright © 2025 Anatoly Petrov <petrov.projects@gmail.com>

# Description

An LRU (Least Recently Used) cache is a data structure that provides quick access 
to items by key and automatically removes the least recently used items in case of 
size exhaustion.

These characteristics make the LRU cache ideal for memoizing arbitrary data 
without the risk of excessive memory usage. 

The proposed implementation (`LruCache` class) utilizes a doubly linked list 
to track item usage and a dictionary for the lookup table.

# Overview

The `LruCache` provides a `MutableMapping` interface similar to the `dict`.

However, unlike a regular `dict`, which has no size limits, the cache size 
is restricted by the `maxsize` parameter specified during the initialization 
of the cache (defaulting to `128`). When the number of items exceeds this limit, 
the `LruCache` automatically removes the least recently used item to make space 
for new entries.

Also, unlike a standard `dict`, which maintains a FIFO (first-in, first-out) order,
the cache employs an MRU (most recently used) order. As a result, all iterators
provided by the `LruCache` — including those from the `__iter__`, `keys`, `values`,
and `items` methods — iterate from the MRU (most recently used) item to the LRU 
(least recently used) item.

Cache synchronization is handled internally using a reentrant lock,
so no action is needed from the end user. Manual synchronization with the `LruCache` 
context manager or through the `acquire` and `release` methods is only necessary 
for implementing atomic operations.

The cache gathers usage statistics, including `hits`, `misses`, `maxsize`, and `currsize`,
which can be accessed using the `cache_info()` method.

# Testing

`pyfastlru` is tested with `pytest` framework.

# License

`pyfastlru` is licensed under the MIT License, see [LICENSE](LICENSE) for more information.
wehavecdathome 0.0.1
Quickly set up non production Continuous Delivery using Docker Compose
Requires Python: >=3.8

# wehavecdathome

Continuous Deliver can get so complicated these days... Do you ever wish you could just.... ```docker compose up``` in ~~production~~ shared test environments?

That is EXACTLY what this project is intended to do.

It should enable you to spin up CD for integration, develop, or even random feature branches in less than 5 minutes.

It is the fastest way to cross of those "Set up Continuous Delivery for X Feature for Cross-Functional Teams" Jira tickets off.

### 0. Install wehavecdathome

```commandline
pip install wehavecdathome
```
install this pip package to get started.


### 1. Enter the Interactive Configuration Utility:

```commandline
wehavecdathome -s
```
This command will walk you through building a configuration file and host directory.

### 2. Test  GIT integration

```commandline
wehavecdathome -p
```

This Command will pull the configured GIT repository, and make sure permissions are set up correctly.

### 3. Test that your application starts up correctly

```commandline
wehavecdathome -t
```

This command will boot your application up so that you can test that everything is working correctly.

### 4. Host your Application
```commandline
wehavecdathome -h
```
This command will continuously monitor your repo, if it sees updates, it will pull them and re-deploy your application.