// Этот файл генерируется с помощью .github/workflows/gh-pages.yml - все локальные изменения в конечном итоге будут потеряны! = ansible-role-core_dependencies Йонас Паммер opensource@jonaspammer.at; :toc: left :toclevels: 2 :toc-placement!: :source-highlighter: rouge

https://galaxy.ansible.com/jonaspammer/core_dependencies[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.core_dependencies-brightgreen[Версия в Galaxy]] // Очень важные статусные значки https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml/badge.svg[Тестирование CI]]

Ansible-роль для установки необходимых системных пакетов, которые требуются для корректной работы различных основных модулей Ansible, а именно:

• ansible.builtin.apt_repository
• ansible.builtin.archive
• ansible.builtin.debconf
• ansible.builtin.dnf
• ansible.builtin.git
• ansible.builtin.subversion
• ansible.builtin.unarchive
• ansible.builtin.user
• ansible.builtin.yum
• ansible.posix.seboolean

Эта роль также гарантирует актуальность кэша пакетов для большинства систем.

В большинстве случаев вы захотите использовать эту роль в сочетании с моей https://github.com/JonasPammer/ansible-role-bootstrap[`bootstrap`-роль].

[ПРИМЕЧАНИЕ] .ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ ===== Эта роль является ответвлением от https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 на GitHub (11 февраля 2022)] (https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[сравнить изменения с этой версии]) (Лицензия Apache 2.0, Авторские права Роберт де Бок (robert@meinit.nl)), в настоящее время с добавленными комментариями к коду. =====

toc::[]

[[meta]] == 🔎 Метаданные Ниже вы можете найти информацию о…

• необходимой версии Ansible для этой роли
• поддерживаемых платформах роли
• зависимостях роли https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies

.link:meta/main.yml[] [source,yaml]

---

---

galaxy_info: role_name: "core_dependencies" description: "Ansible-роль для установки зависимостей для поддержки основных модулей Ansible. Основана на роли core_dependencies от robertdebock."

author: "jonaspammer" license: "MIT"

min_ansible_version: "2.11" platforms: # примечание: текст после "активно тестируется: " представляет собой имя образа Docker - name: EL # (Enterprise Linux) versions: - "9" # активно тестируется: rockylinux9 - name: Fedora versions: - "38" # активно тестируется: fedora38 - "39" # активно тестируется: fedora39 - name: Debian versions: - bullseye # активно тестируется: debian11 - bookworm # активно тестируется: debian12 - name: Ubuntu versions: - focal # активно тестируется: ubuntu2004 - jammy # активно тестируется: ubuntu2204

galaxy_tags: []

dependencies: []

[[requirements]] == 📌 Требования // Здесь должны быть указаны любые предварительные условия, которые могут не охватываться этой ролью или самим Ansible. Пользователь Ansible должен иметь возможность become.

Коллекция https://galaxy.ansible.com/community/general[`community.general`] должна быть установлена на контроллере Ansible.

[[variables]] == 📜 Переменные роли // Здесь должно быть описание настраиваемых переменных для этой роли // и любые переменные, которые могут/должны быть установлены через параметры роли. // Все переменные, которые читаются из других ролей и/или глобальной области (т.е. hostvars, group vars и т.д.) // также должны быть указаны здесь.

[[public_vars]] == 📜 Факты/Переменные, определенные этой ролью

Каждая переменная, перечисленная в этом разделе, определяется динамически при выполнении этой роли (и может быть переопределена только с помощью ansible.builtin.set_facts) и предназначена для использования не только внутренними.

[[tags]] == 🏷️ Теги

// Ознакомьтесь с https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags // для замечательного примера группировки задач с использованием тегов

Задачи помечены следующими https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[тегами]:

[cols="1,1"] |=== |Тег | Цель

2+| У этой роли пока нет официально задокументированных тегов.

|===

Вы можете использовать Ansible для пропуска задач или для выполнения определенных задач с помощью этих тегов. По умолчанию все задачи выполняются, если не указаны теги.

[[dependencies]] == 👫 Зависимости // Здесь должен быть список других ролей, // а также любые детали, касающиеся параметров, которые могут потребовать установки для других ролей, // или переменных, которые используются из других ролей.

[[example_playbooks]] == 📚 Примеры использования плейбуков // Включение примеров того, как использовать эту роль в плейбуке для распространенных сценариев, всегда полезно для пользователей.

[ПРИМЕЧАНИЕ]

Эта роль является частью https://github.com/JonasPammer/ansible-roles[ многих совместимых роль-подборок для определенных целей].

Машина должна быть подготовлена. В CI это делается в molecule/resources/prepare.yml, который получает свои "мягкие зависимости" из requirements.yml:

.link:molecule/resources/prepare.yml[] [source,yaml]

---

---

• name: prepare hosts: all become: true gather_facts: false

  roles:

  • role: jonaspammer.bootstrap

---

Следующая диаграмма является компиляцией "мягких зависимостей" этой роли также как и рекурсивного дерева их мягких зависимостей.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[ граф зависимостей requirements.yml jonaspammer.core_dependencies] ====

.Минимально жизнеспособный плей

[source,yaml]

---

• hosts: servers:&provisioned name: Подготовка linux-машин для управления Ansible. gather_facts: false

  roles:

  • role: jonaspammer.core_dependencies

---

====

.Более общий плей

[source,yaml]

---

• hosts: servers:&provisioned name: Подготовка linux-машин для управления Ansible. become: false gather_facts: false

  roles:

  • role: jonaspammer.bootstrap
  • role: jonaspammer.core_dependencies become: "{{ bootstrap_become | default(omit) }}" become_user: "{{ bootstrap_become_user | default(omit) }}"

---

====

[[tested-distributions]] == 🧪 Тестируемые дистрибуции

Роль может работать на разных дистрибуциях, таких как Red Hat Enterprise Linux (RHEL), хотя для этой конкретной дистрибуции нет теста.

// хорошая ссылка на то, что нужно следовать - это самый звездный и закрепленный проект geerlingguy: // https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml |=== | Семейство ОС | Дистрибуция | Дата выхода дистрибуции | Дата окончания поддержки дистрибуции | Сопутствующий образ Docker

// https://endoflife.date/rocky-linux | Rocky | Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 в обличии]) | 2021-06 | 2029-05 | https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky | Rocky Linux 9 | 2022-07 | 2032-05 | https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://endoflife.date/fedora (13 месяцев) | RedHat | Fedora 39 | 2023-11 | 2024-12 | https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://ubuntu.com/about/release-cycle | Debian | Ubuntu 20.04 LTS | 2021-04 | 2025-04 | https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 22.04 LTS | 2022-04 | 2027-04 | https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 11 | 2021-08 | 2024-06 (2026-06 LTS) | https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 12 | 2023-06 | 2026-06 (2028-06 LTS) | https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]] |===

[[tested-ansible-versions]] == 🧪 Тестируемые версии Ansible

Тестируемые версии anbsible пытаются соответствовать https://github.com/ansible-collections/community.general#tested-with-ansible[ шаблону поддержки коллекции community.general от Ansible]. На момент написания это:

• 2.13 (Ansible 6)
• 2.14 (Ansible 7)
• 2.15 (Ansible 8)
• 2.16 (Ansible 9)

[[development]] == 📝 Разработка // Значки о соглашениях в этом проекте https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Согласованные коммиты]] https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-core_dependencies/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-core_dependencies/master.svg[статус pre-commit]] // image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]] === 📌 Зависимости машины для разработки

• Python 3.10 или выше
• Docker

[[development-dependencies]] === 📌 Зависимости для разработки Зависимости для разработки определены в https://pip.pypa.io/en/stable/user_guide/#requirements-files[файле требований pip] под названием requirements-dev.txt. Ниже приведены примеры инструкций по установке для Linux:

---

"по желанию": создать виртуальную среду python и активировать ее для текущей сессии оболочки

$ python3 -m venv venv $ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt

[[development-guidelines]] === ℹ️ Рекомендации по разработке Ansible Roles

Пожалуйста, ознакомьтесь с моими https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[ Рекомендациями по разработке Ansible Roles].

Если вам интересно, я также записал некоторые https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[ Общие рекомендации по разработке Ansible Roles (Лучшие) Практики].

[[versioning]] === 🔢 Версионирование

Версии определяются с использованием https://git-scm.com/book/en/v2/Git-Basics-Tagging[тегов], которые, в свою очередь, https://galaxy.ansible.com/docs/contributing/version.html[признаются и используются] Ansible Galaxy.

Версии не должны начинаться с v.

Когда новый тег публикуется, https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml[ работа GitHub CI] (image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml/badge.svg[CI релиза]) занимается импортом роли в мой аккаунт Ansible Galaxy.

[[testing]] === 🧪 Тестирование Автоматические тесты выполняются при каждом взносе с использованием рабочих процессов GitHub.

Тесты в основном решают задачи запуска https://molecule.readthedocs.io/en/latest/[Molecule] на <<tested-distributions,различных наборах дистрибуций linux>> и использовании <<tested-ansible-versions,различных версий ansible>>.

Тест Molecule также включает этап, который проверяет все плейбуки ansible с использованием https://github.com/ansible/ansible-lint#readme[`ansible-lint`] для проверки на соответствие лучшим практикам и поведению, которое потенциально может быть улучшено.

Чтобы запустить тесты, просто запустите tox в командной строке. Вы можете передать дополнительную переменную окружения, чтобы определить дистрибуцию Docker-контейнера, который будет развернут Molecule:

---

$ MOLECULE_DISTRO=ubuntu2204 tox

Для списка возможных значений, переданных MOLECULE_DISTRO, ознакомьтесь с матрицей, определенной в link:.github/workflows/ci.yml[].

==== 🐛 Отладка контейнера Molecule

1. Запустите ваши тесты Molecule с опцией MOLECULE_DESTROY=never, например:

• [subs="quotes,macros"]

---

$ MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5# ... TASK [ansible-role-pip : (сокрыто).] pass:[************************] failed: [instance-py3-ansible-9] => changed=false ... pass:[___________________________________ summary ____________________________________] pre-commit: команды выполнены успешно ERROR: py3-ansible-9: команды не выполнены

---

2. Узнайте имя контейнера Docker, созданного Molecule:

• [subs="quotes"]

---

$ docker ps #30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" 8 минут назад Запущен 8 минут instance-py3-ansible-9

---

3. Зайдите в оболочку bash контейнера и выполняйте отладку:

• [subs="quotes"]

---

$ docker exec -it #30e9b8d59cdf# /bin/bash

root@instance-py3-ansible-2:/#

• [СОВЕТ]

  Если сбой, который вы пытаетесь отладить, является частью вашего этапа verify.yml, а не фактического converge.yml, вы можете захотеть знать, что вывод модулей Ansible (vars), хостов (hostvars) и переменных окружения был сохранен в файлы на обоих провайдере и внутри машины Docker по:

• /var/tmp/vars.yml (содержит переменные хоста под ключом hostvars)
• /var/tmp/environment.yml

  используйте grep, cat или передавайте их по своему усмотрению!

• [СОВЕТ]

  Вы также можете узнать, что упомянутые выше файлы прикреплены к артефактам GitHub CI конкретного выполнения рабочего процесса. + Это позволяет проверить разницу между запусками и таким образом помочь в отладке того, что вызвало деградацию или сбой в целом.

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]

4. После завершения отладки выйдите из него и уничтожьте контейнер:

• [subs="quotes"]

---

root@instance-py3-ansible-2:/# выход

$ docker stop #30e9b8d59cdf#

$ docker container rm #30e9b8d59cdf# или $ docker container prune

---

==== 🐛 Отладка версий установленных пакетов локально

Хотя это стандартная функция в tox 3, это https://github.com/tox-dev/tox/pull/2794[сейчас] происходит только тогда, когда tox распознает наличие переменной CI. Например:

---

$ CI=true tox

[[development-container-extra]] === 🧃 СОВЕТ: Идеальная среда разработки в контейнере

Этот проект предлагает определение "Окружения разработки в контейнере с 1 щелчком".

Этот контейнер даже позволяет запускать контейнеры Docker внутри него (Docker-In-Docker, dind), что позволяет выполнять Molecule.

Чтобы использовать его:

1. Убедитесь, что вы соответствуете link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[ системным требованиям контейнеров разработки Visual Studio Code], при необходимости следуя разделе Установка на связанной странице. + Это включает: установку Docker, установку самих приложений Visual Studio Code и установку необходимых расширений.
2. Склонируйте проект на свой компьютер
3. Откройте папку репозитория в Visual Studio Code (Файл - Открыть папку…).
4. Если вы получите уведомление в правом нижнем углу о наличии определения devcontainer, вы можете нажать соответствующую кнопку, чтобы войти в него. В противном случае вы также можете выполнить команду Visual Studio Remote-Containers: Open Folder in Container самостоятельно (Вид - Командная палитра -> введите упомянутую команду).

[СОВЕТ]

Я рекомендую использовать Remote-Containers: Rebuild Without Cache and Reopen in Container время от времени, так как функция devcontainer иногда имеет проблемы с правильным распознаванием изменений в своем определении. ====

[ПРИМЕЧАНИЕ]

Вам может понадобиться настроить свою хостовую систему, чтобы контейнер мог использовать ваши SSH/GPG ключи.

Процедура описана https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[ в официальной документации devcontainer в разделе "Обмен учетными данными Git с вашим контейнером"]. =====

[[cookiecutter]] === 🍪 CookieCutter

Этот проект должен быть синхронизирован с https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, от которого он изначально был шаблонирован] с использованием https://github.com/cruft/cruft[cruft] (если возможно) или вручную (если необходимо) в максимально возможной степени.

.Официальный пример использования cruft update

---

image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Официальный пример использования cruft update]

---

==== 🕗 Журнал изменений Когда новый тег публикуется, соответствующий GitHub релиз будет создан Содержателем репозитория для предоставления соответствующего человеческого журнала изменений с заголовком и описанием.

[[pre-commit]] === ℹ️ Общие правила стилистики и линтинга Общие правила стилистики и линтинга https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*автоматически* поддерживаются в соответствии со стандартами] различными https://pre-commit.com/[`pre-commit`] хуками, по крайней мере, отчасти.

Автоматическое выполнение pre-commit происходит при каждом взносе с использованием https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>. Запросы на Pull Request даже автоматически исправляются тем же инструментом, по крайней мере, с помощью хуков, которые автоматически изменяют файлы.

[ПРИМЕЧАНИЕ]

Не путайте: Хотя некоторые хуки pre-commit могут быть способны предупредить вас о недостатках, анализируемых в синтаксисе скриптов или даже коде отчасти (по какой причине хуки pre-commit являются частью тестового набора), сам pre-commit не запускает никаких реальных тестовых наборов. Для получения информации о тестировании, обратитесь к <>. ====

[СОВЕТ]

[[note_pre-commit-ci]] Тем не менее, я рекомендую вам интегрировать pre-commit в свой локальный процесс разработки самостоятельно.

Это можно сделать, перейдя в каталог вашего склонированного проекта и запустив pre-commit install. Сделав это, вы заставите git выполнять проверки pre-commit при каждом вашем коммите, прерывая сам коммит, если произошел сбой хука.

Вы также можете, например, выполнить хуки pre-commit в любое время, запустив pre-commit run --all-files.

[[contributing]] == 💪 Участие https://open.vscode.dev/JonasPammer/ansible-role-core_dependencies[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Открыть в Visual Studio Code]] image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[Запросы Pull под welcome]

// Включено в README.adoc :toc: :toclevels: 3

Следующие разделы носят общий характер и предназначены для помощи новым участникам. Фактическая "Документация по разработке" этого проекта находится в разделе <>.

=== 🤝 Введение Прежде всего, спасибо, что рассматриваете возможность участия в этом проекте.

Следование этим рекомендациям помогает сообщить о том, что вы уважаете время разработчиков, которые управляют и развивают этот проект с открытым исходным кодом. В свою очередь, им следует уважительно относиться к вашему вопросу, оценивать изменения и помогать вам завершить ваши запросы на изменения.

[[cookiecutter--contributing]] === 🍪 CookieCutter Этот проект несет многие из своих файлов благодаря https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, от которого он изначально был шаблон].

Пожалуйста, проверьте, применимо ли редактирование, о котором вы думаете, на самом деле к шаблону, и если да, внесите соответствующие изменения там. Ваше изменение также может быть применимо частично к шаблону и частично к чему-то конкретному для этого проекта, в таком случае вы создадите несколько запросов на изменения.

=== 💬 Согласованные коммиты

Обычный участник может не беспокоиться о соблюдении https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__спецификации__] https://www.conventionalcommits.org/en/v1.0.0/[__по определению__], так как запросы на изменения объединяются в один коммит в проекте. Только основные участники, т.е. те, кто имеет права на изменение веток этого проекта, должны следовать ему (например, для того, чтобы автоматическое определение версии и генерация журнала изменений работали).

=== 🚀 Начало работы

Вклад в этот репозиторий осуществляется с помощью вопросов и запросов на изменения (PR). Некоторые общие рекомендации, которые охватывают оба:

• Ищите существующие вопросы и PR перед созданием собственного.
• Если вы никогда не участвовали, посмотрите https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[ руководство для новичков на блоге Auth0] для получения ресурсов и советов по началу работы.

==== Вопросы

Вопросы должны использоваться для сообщения о проблемах, запроса новой функции или обсуждения потенциальных изменений перед созданием PR. Когда вы https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[ создаете новый вопрос], загружается шаблон, который поможет вам собрать и предоставить информацию, необходимую для нашего расследования.

Если вы найдете вопрос, который касается проблемы, с которой вы сталкиваетесь, пожалуйста, добавьте свою информацию о воспроизводимости к существующему вопросу вместо того, чтобы создавать новый. Добавление реакции https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[может помочь] в указании нашим администраторов, что определенная проблема затрагивает больше, чем просто докладчик.

==== Запросы на изменение

Запросы на изменение этого проекта всегда приветствуются и могут быть быстрым способом реализовать вашу исправление или улучшение в следующем релизе. https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[В общем], PR должны:

• Исправлять/добавлять только функциональность, в которой идет речь ИЛИ устранять широко распространенные проблемы с пробелами/стилем, а не и то, и другое.
• Добавлять юнит или интеграционные тесты для исправленной или измененной функциональности (если уже существует тестовый набор).
• Касаться одной проблемы
• Содержать документацию в репозитории
• Быть сопровождены полным шаблоном запроса на изменение (загружается автоматически при создании PR).

Для изменений, которые касаются основной функциональности или требовали бы разрыва изменений (например, при мажорном релизе), лучше сначала открыть вопрос для обсуждения вашего предложения.

В общем, мы следуем "форк-и-пул" Git рабочему процессу:

1. Форкните репозиторий в свой аккаунт Github
2. Склонируйте проект на свой компьютер
3. Создайте ветку локально с кратким, но описательным именем
4. Зафиксируйте изменения в ветке
5. Следуйте любым требованиям к форматированию и тестированию, специфичным для этого репозитория
6. Запушьте изменения в ваш форк
7. Откройте PR в нашем репозитории и следуйте шаблону PR, чтобы мы могли эффективно рассмотреть изменения.

[[changelog]] == 🗒 Журнал изменений Пожалуйста, обратитесь к https://github.com/JonasPammer/ansible-role-core_dependencies/releases[странице релизов этого репозитория] для получения человеческого журнала изменений, соответствующего https://github.com/JonasPammer/ansible-role-core_dependencies/tags[тегам (версиям) этого проекта].

Обратите внимание, что этот проект соответствует семантическому версионированию. Пожалуйста, сообщайте о любых случайных разрушающих изменениях при обновлении минорной версии.

[[license]] == ⚖️ Лицензия

.link:LICENSE[]

Лицензия MIT

Авторские права (c) 2022, Йонас Паммер

Настоящим предоставляется бесплатное право любому лицу, получившему копию данного программного обеспечения и сопутствующей документации (в дальнейшем "Программное обеспечение"), свободно распоряжаться с Программным обеспечением без каких-либо ограничений, включая, помимо прочего, права использовать, копировать, изменять, объединять, публиковать, распространять, sublicense и/или продавать экземпляры Программного обеспечения, а также разрешить лицам, которым Программное обеспечение предоставляется, делать это с соблюдением следующих условий:

Указанное выше уведомление об авторских правах и данное разрешение должны быть включены во все копии или значительные части Программного обеспечения.

ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ", БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ГАРАНТИЯМИ ТОРГОВОЙ ПРИГОДНОСТИ, ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ И НАРУШЕНИЯ. В НИКАКОМ СЛУЧАЕ АВТОРЫ ИЛИ ДЕРЖАТЕЛИ АВТОРСКИХ ПРАВ НЕ НОСЯТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ПРЕТЕНЗИИ, УБЫТКИ ИЛИ ДРУГИЕ ОТВЕТСТВЕННОСТИ, НИ В РАМКАХ КОНТРАКТА, ДЕЛИКТА ИЛИ ИНЫХ, ВОЗНИКНУЩИЕ В СВЯЗИ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ ИЛИ ИСПОЛЬЗОВАНИЕМ ИЛИ ДРУЖЕСКИМИ ОТНОШЕНИЯМИ С НИМ.

---