Metadata-Version: 2.4
Name: georchestra_analytics_cli
Version: 2.0.0
Summary: A CLI for the geOrchestra analytics module
Home-page: https://github.com/georchestra/analytics
Author: Jean Pommier
Author-email: jean.pommier@pi-geosolutions.fr
License: GPL-3.0-only
Project-URL: Documentation, https://docs.georchestra.org/analytics
Project-URL: Source, https://github.com/georchestra/analytics
Platform: any
Classifier: Development Status :: 4 - Beta
Classifier: Programming Language :: Python
Requires-Python: >=3.10
Description-Content-Type: text/markdown; charset=UTF-8
Requires-Dist: importlib-metadata; python_version < "3.8"
Requires-Dist: Click
Requires-Dist: prometheus_client<1.0,>=0.21.0
Requires-Dist: pyaml_env<2.0,>=1.2
Requires-Dist: pydantic
Requires-Dist: SQLAlchemy
Requires-Dist: psycopg2-binary
Requires-Dist: python-dateutil
Requires-Dist: ua-parser[regex]
Requires-Dist: Jinja2
Provides-Extra: dev
Requires-Dist: tox; extra == "dev"
Requires-Dist: black; extra == "dev"
Requires-Dist: isort; extra == "dev"
Provides-Extra: testing
Requires-Dist: setuptools; extra == "testing"
Requires-Dist: pytest; extra == "testing"
Requires-Dist: pytest-cov; extra == "testing"

# geOrchestra analytics CLI

A CLI tool to process access log data for geOrchestra analytics.

Different sources are accepted for access log data:
- A postgresql buffer table reproducing the Opentelemetry access log data structure.
- File-based access logs. It is expected to contain CLF-like (or, say, text-based) access log entries. They are parsed using a regular expression pattern. 
- Fake access logs can also be generated for dev/testing/discovery purposes

The result is written in a postgresql table, preferably a timescaleDB hypertable, since a lot of data will be written and you will want time-enabled data management.

To know more about it, please read the doc on https://docs.georchestra.org/analytics

## Install

Create a virtualenv and install this package:
```bash
python -m venv .venv
source .venv/bin/activate
pip install georchestra_analytics_cli
```


## Build & publish

This project is based on [pyScaffold](https://pypi.org/project/PyScaffold/) and uses [tox](https://tox.wiki/en/latest/installation.html) for the build.

There is no CI as of now, it's done manually.

To install `tox`, we recommend installing it with [pipx](https://pypi.org/project/pipx):
```bash
pipx install tox
tox --help
```

### Build the project:
```bash
tox -e clean,build
```

### Publish to Pypi:
To publish to Pypi, there are some prerequisites:

- You must set a git tag on your current commit (e.g. `git tag -a 0.1.0 -m "v0.1.0"`)
- Your git working tree should be clean (nothing pending, `git status` should report `nothing to commit, working tree clean`).

This ensures that `setuptools_scm` will detect a clean version. `setuptools_scm` extracts automatically the version from the `git describe` information, behind the scene.

You will also also need a pypi token to publish

Publish on test.pypi.org:
```bash
tox -e publish
```

Publish on pypi.org:
```bash
tox -e publish -- --repository pypi
```

### Docker build:

We provide you with a utility script, `./docker_build.sh`.  
It takes 2 options:

- `--mode=`: the build mode (one of [dev, test, pypi]). `test` will try to fetch the package from test.pypi while `pypi` will try to fetch it from the main pypi repo. `dev` will build the local code base.
- `--version=`: allows to set the version to use. On dev mode, it can be arbitrary. 

Examples:

- Build from the latest version from pypi:
```bash
./docker_build.sh --mode=pypi
```
- Build from the 0.1.0 version from pypi: (version 0.1.0 has to exist there)
```bash
./docker_build.sh --mode=pypi --version=0.1.0
```
- Build from the 0.1.0 version from test.pypi: (version 0.1.0 has to exist there)
```bash
./docker_build.sh --mode=test --version=0.1.0
```
- Build from local codebase, tag it 0.1.0-dirty:
```bash
./docker_build.sh --mode=dev --version=0.1.0-dirty
```
- Build from local codebase, use the auto-generated tag:
```bash
./docker_build.sh --mode=dev
```
