interlis2py 0.1.2__tar.gz

interlis2py-0.1.2/.dockerignore

@@ -0,0 +1,9 @@
+__pycache__/
+*.pyc
+*.pyo
+venv/
+.env
+.coverage
+build
+docs
+.venv

interlis2py-0.1.2/.gitattributes

@@ -0,0 +1,4 @@
+*.zip binary
+*.png binary
+*.gif binary
+*.mp4 binary

interlis2py-0.1.2/.gitignore

@@ -0,0 +1,45 @@
+.idea/
+.vscode/
+
+*.egg-info/
+*.pyc
+*\.bak
+\.fuse*
+.coverage
+.DS_Store
+*__pycache__
+reqs.txt
+
+docs/_build/
+docs/site
+dist/
+build/
+htmlcov/
+
+ili2py.spec
+
+.tox/
+node_modules
+
+dependency-graphs/
+test-results/
+uml-diagrams/
+pydoer-graphs/
+
+src/ili2py/generated
+generated
+test.puml
+src/ili2py/test.py
+src/ili2py/test1.py
+src/ili2py/test2.py
+src/ili2py/test3.py
+.generated/*
+!.generated/.gitkeep
+
+src/ili2py_interface
+src/ili2py/_version.py
+
+tests/data/*/*.py
+tests/data/models/*/*.xtf
+tests/data/models/*/*.xml
+/.venv/

interlis2py-0.1.2/.pre-commit-config.yaml

@@ -0,0 +1,28 @@
+# reference data and raw xsdata output are kept as delivered
+exclude: ^(tests/data/|src/ili2py/interfaces/interlis/interlis_24/ilismeta/)
+
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: mixed-line-ending
+        args: ["--fix=lf"]
+
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.17.1
+    hooks:
+      - id: ruff-check
+        args: [ --fix ]
+      - id: ruff-format
+
+  # uses the project environment, so the result matches `make check` and CI
+  - repo: local
+    hooks:
+      - id: mypy
+        name: mypy
+        entry: uv run --locked --group test mypy src/ili2py tests
+        language: system
+        types: [python]
+        pass_filenames: false

interlis2py-0.1.2/.python-version

@@ -0,0 +1 @@
+3.12

interlis2py-0.1.2/CHANGELOG.md

@@ -0,0 +1,10 @@
+# Changelog
+
+From 0.1.0 on, the changes of each version are listed in the release notes on the
+[releases page](https://github.com/rudert-geoinformatik/ili2py/releases). They are generated from the merged pull requests.
+
+## 0.0.1 (2025-01-27)
+
+## 0.0.0 (2023-10-28)
+
+Initial version

interlis2py-0.1.2/CONTRIBUTING.md

@@ -0,0 +1,246 @@
+# Contributing
+
+Thank you for considering reading this guide!
+Contributions are welcome :)
+
+
+* [Types of Contributions](#Types-of-Contributions)
+* [Contributor Setup](#Setting-Up-the-Code-for-Local-Development)
+* [Contributor Guidelines](#Contributor-Guidelines)
+* [Contributor Testing](#Testing)
+* [Core Committer Guide](#Core-Committer-Guide)
+
+
+## Types of Contributions
+
+You can contribute in many ways:
+
+### Report Bugs
+
+Report bugs at [https://github.com/rudert-geoinformatik/ili2py/issues](https://github.com/rudert-geoinformatik/ili2py/issues).
+W
+Stambling upon a Bug means encountering different behaviour than the expected/advertised one. When you are reporting a bug, please include the following infromation by filling in [the template](https://github.com/rudert-geoinformatik/ili2py/.github/blob/master/.github/ISSUE_TEMPLATE/bug_report.md).
+
+* Your operating system name and version.
+* Any details about your local setup that might be helpful in troubleshooting.
+* If you can, provide detailed steps to reproduce the bug.
+* If you don't have steps to reproduce the bug, just note your observations in as much detail as you can. Questions to start a discussion about the issue are welcome.
+
+### Fix Bugs
+
+Look through the GitHub issues for bugs. Anything tagged with "bug" is open to whoever wants to implement it. See [Contributor Setup](#Setting-Up-the-Code-for-Local-Development) to get started.
+
+### Implement Features
+
+Look through the GitHub issues for features. Anything tagged with "enhancement" and "please-help" is open to whoever wants to implement it.
+
+Please do not combine multiple feature enhancements into a single pull request.
+
+See [Contributor Setup](#Setting-Up-the-Code-for-Local-Development) to get started.
+
+### Write Documentation
+
+ili2py could always use more documentation, whether as part of the official ili2py docs, in docstrings, etc.
+
+If you want to review your changes on the documentation locally, you can do:
+
+```bash
+make doc-serve
+```
+
+This will compile the documentation (into html) and start watching the files for changes, recompiling as you save.
+You can open it in your browser at http://127.0.0.1:8000 !
+
+### Submit Feedback
+
+The best way to send feedback is to file an issue at [https://github.com/rudert-geoinformatik/ili2py/issues](https://github.com/rudert-geoinformatik/ili2py/issues).
+
+If you are proposing a feature:
+
+* Explain in detail how it would work.
+* Keep the scope as narrow as possible, to make it easier to implement.
+* Remember that this is a volunteer-driven project, and that contributions are welcome :)
+
+## Setting Up the Code for Local Development
+
+Here's how to set up `ili2py` for local development.
+
+1. Fork the `ili2py` repo on GitHub.
+2. Clone your fork locally:
+
+```bash
+git clone git@github.com:rudert-geoinformatik/ili2py.git
+```
+
+3. Install your local copy with [uv](https://docs.astral.sh/uv/). This creates `.venv` with the package (editable) and the `dev` and `test` dependency groups:
+
+```bash
+cd ili2py
+make install-test
+uv run pre-commit install
+```
+
+4. Create a branch for local development:
+
+```bash
+git checkout -b name-of-your-bugfix-or-feature
+```
+
+Now you can make your changes locally.
+
+1. When you're done making changes, check that your changes pass the tests locally:
+
+```bash
+make test
+make lint
+make check
+```
+
+`make format` applies the ruff fixes and formatting. If you want to produce a built tar.gz and wheel distributions:
+
+```bash
+make build
+```
+
+1. Ensure that your feature or commit is fully covered by tests. Check the coverage report that is shown on the console when you run `make test-coverage`.
+
+1. Commit your changes and push your branch to GitHub:
+
+```bash
+git add -p
+git commit -m "Your detailed description of your changes."
+git push origin name-of-your-bugfix-or-feature
+```
+
+8. Submit a pull request through the GitHub website.
+
+## Contributor Guidelines
+
+### Pull Request Guidelines
+
+Before you submit a pull request, check that it meets these guidelines:
+
+1. The pull request should include tests.
+2. The pull request should be contained: if it's too big consider splitting it into smaller pull requests.
+3. If the pull request adds functionality, the docs should be updated.
+4. The pull request must pass all CI/CD jobs before being ready for review.
+5. If one CI/CD job is failing for unrelated reasons you may want to create another PR to fix that first.
+
+### Coding Standards
+
+* Single Responsibility of Units
+* Modularity
+* Composition over Inheritance
+
+
+## Testing
+
+Tests run with pytest, see the [pytest usage docs](https://docs.pytest.org/en/stable/how-to/usage.html) for selecting tests.
+
+To run all tests:
+
+```bash
+make test
+```
+
+To only run test cases matching the string 'smoke_test':
+
+```bash
+uv run --group test pytest -k 'smoke_test'
+```
+
+To run the tests with another python version (e.g. 3.13):
+
+```bash
+uv run --isolated --python 3.13 --group test pytest
+```
+
+
+## Core Committer Guide
+
+### Vision and Scope
+
+Core committers, use this section to:
+
+* Guide your instinct and decisions as a core committer
+* Limit the codebase from growing infinitely
+
+#### API Accessible
+
+* Modular API striving for statelessness
+* Easy to use without having to think too hard
+* Flexible for more complex use cases
+* Easily extensible
+
+#### Extensible
+
+* Modular Design
+* Aim for statelessness
+
+
+#### Fast and Focused
+
+ili2py is designed to do one thing, and do that one thing very well.
+
+* Cover the important use cases and as little as possible beyond that :)
+
+
+#### Inclusive
+
+* Cross-platform and cross-version support
+
+#### Stable
+
+* Aim for high test coverage and covering corner cases
+* No pull requests will be accepted that drop test coverage on any platform
+* Stable APIs that tool builders can rely on
+
+
+### Process: Pull Requests
+
+How to prioritize pull requests, from most to least important:
+
+* Fixes for broken tests. Broken means broken on any supported platform or Python version.
+* Extra tests to cover corner cases.
+* Minor edits to docs.
+* Bug fixes.
+* Major edits to docs.
+* Features.
+
+#### Pull Requests Review Guidelines
+- Think carefully about the long-term implications of the change. How will it affect existing projects that are dependent on this? If this is complicated, do we really want to maintain it forever?
+- Take the time to get things right, PRs almost always require additional improvements to meet the bar for quality. **Be very strict about quality.**
+- When you merge a pull request take care of closing/updating every related issue explaining how they were affected by those changes. Also, remember to add the author to `AUTHORS.md`.
+
+### Process: Issues
+
+If an issue is a bug that needs an urgent fix, mark it for the next patch release.
+Then either fix it or mark as please-help.
+
+For other issues: encourage friendly discussion, moderate debate, offer your thoughts.
+
+### Process: Roadmap
+
+The roadmap located [here](https://github.com/rudert-geoinformatik/ili2py/milestones?direction=desc&sort=due_date&state=open)
+
+Due dates are flexible.
+
+### Process: Release
+
+* Follow semantic versioning. Look at: [http://semver.org](http://semver.org). We stay on `0.x` while the API is still changing.
+* The git tag is the only source of the version. setuptools-scm derives it at build time, nobody writes a version into the code.
+* Untagged builds get a dev version like `0.1.1.dev3+g1a2b3c4`.
+
+Releasing:
+
+1. Make sure everything for the release is merged to `master`. There is no changelog to update: the release notes are generated from the merged pull requests, so give pull requests meaningful titles.
+2. Tag and push:
+
+```bash
+git tag -a vX.Y.Z -m "vX.Y.Z"
+git push origin vX.Y.Z
+```
+
+Alternatively create the release with a new tag in the GitHub UI.
+
+3. CI builds and tests, creates the GitHub release with generated release notes, binaries, wheel and sdist and publishes the package to PyPI as `interlis2py`.

interlis2py-0.1.2/Dockerfile

@@ -0,0 +1,32 @@
+FROM python:3.13-slim
+
+COPY --from=ghcr.io/astral-sh/uv:0.13.1 /uv /bin/uv
+
+# manually set cache dir to /tmp to prevent permission issues
+ENV RUFF_CACHE_DIR=/tmp/ruff_cache
+# use the interpreter of the base image instead of .python-version
+ENV UV_PYTHON=/usr/local/bin/python3 \
+    UV_PYTHON_DOWNLOADS=never \
+    UV_COMPILE_BYTECODE=1 \
+    UV_LINK_MODE=copy \
+    UV_NO_CACHE=1
+
+WORKDIR /app
+
+# dependencies first to keep them in a separate layer
+COPY pyproject.toml uv.lock /app/
+RUN uv sync --locked --no-dev --no-install-project
+
+# the version comes from the git tags via setuptools-scm, so git is needed while installing the project.
+# without .git (e.g. built from a tarball) pass the version: --build-arg SETUPTOOLS_SCM_PRETEND_VERSION=0.1.0
+ARG SETUPTOOLS_SCM_PRETEND_VERSION
+COPY . /app
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends git \
+    && uv sync --locked --no-dev \
+    && apt-get purge -y --auto-remove git \
+    && rm -rf /var/lib/apt/lists/*
+
+USER 1000
+
+ENTRYPOINT ["/app/.venv/bin/python", "-m", "ili2py.cli"]