# -*- coding: utf-8 -*-
from setuptools import setup

packages = \
['wap', 'wap.commands']

package_data = \
{'': ['*']}

install_requires = \
['arrow>=0.17.0,<0.18.0',
 'attrs>=20.3.0,<21.0.0',
 'click>=7.1.2,<8.0.0',
 'colorama>=0.4.4,<0.5.0',
 'requests>=2.25.1,<3.0.0',
 'strictyaml>=1.3.2,<2.0.0']

entry_points = \
{'console_scripts': ['wap = wap.__main__:main']}

setup_kwargs = {
    'name': 'wow-addon-packager',
    'version': '0.5.2',
    'description': 'A user-friendly World of Warcraft addon packager',
    'long_description': 'wap (WoW Addon Packager)\n========================\n\n.. image:: https://github.com/t-mart/wap/actions/workflows/ci.yml/badge.svg?branch=master\n   :target: https://github.com/t-mart/wap/actions/workflows/ci.yml\n   :alt: GitHub Actions status for master branch\n\n.. image:: https://codecov.io/gh/t-mart/wap/branch/master/graph/badge.svg?token=AVOA4QWTBL\n   :target: https://codecov.io/gh/t-mart/wap\n   :alt: Code Coverage on codecov.io\n\n.. image:: https://img.shields.io/pypi/v/wow-addon-packager\n   :target: https://pypi.org/project/wow-addon-packager/\n   :alt: Latest release on PyPI\n\n.. image:: https://img.shields.io/badge/code%20style-black-000000.svg\n   :target: https://github.com/psf/black\n   :alt: Code styled with black\n\n.. image:: https://img.shields.io/github/license/t-mart/wap\n   :target: https://github.com/t-mart/wap/blob/master/LICENSE\n   :alt: MIT licensed\n\n|\n\n*wap* is a user-friendly World of Warcraft addon packager.\n\n.. image:: https://raw.githubusercontent.com/t-mart/wap/master/docs/demo.gif\n   :alt: wap demo\n\nFeatures\n--------\n\n- Builds and uploads your addons to CurseForge\n- Creates retail or classic WoW addons, or both!\n- Installs your addons to your Addons folder for fast development feedback\n- Generates valid TOC files automagically\n- Sets up new addon projects quickly, ready to go with one command\n- Consolidates all configuration in one easy-to-edit file\n- Supports Windows, macOS, and Linux\n\nTable of Contents\n-----------------\n\n.. contents::\n\nGetting started\n---------------\n\nInstallation\n************\n\n1. `Download <https://www.python.org/downloads/>`_ and install Python\n2. Install *wap* with pip:\n\n   .. code-block:: console\n\n      $ pip install -U wow-addon-packager\n\nCreate a new addon project\n**************************\n\n.. code-block:: console\n\n  wap quickstart MyAddon  # or whatever name you\'d like!\n\nand answer the prompted questions. Don\'t worry too much about your answers -- you can\nalways change them later in your configuration file.\n\nBuilding\n********\n\nBuilding your addon packages it up into a single directory and creates a zip file of it.\n\n.. code-block:: console\n\n  wap build\n\nDeveloper Install\n*****************\n\nInstead of copy-pasting folders into your WoW installation to test out your work, *wap*\ncan do that for you:\n\n.. code-block:: console\n\n  # Windows\n  wap dev-install --wow-addons-path "C:\\Program Files (x86)\\World of Warcraft\\_retail_\\Interface\\AddOns"\n\n  # macOS\n  wap dev-install --wow-addons-path "/Applications/World of Warcraft/_retail_/Interface/AddOns"\n\nChange ``_retail_`` to ``_classic_`` if you want to install your classic build.\n\n*wap* is smart in determining from your ``--wow-addons-path`` if it needs to install\nthe retail or classic build of your addon.\n\nUploading\n*********\n\n.. code-block:: console\n\n  wap upload --addon-version 0.0.1 --curseforge-token "<your-token>"\n\nYou can generate a new token at `<https://authors.curseforge.com/account/api-tokens>`_.\n\nFurther Help\n************\n\n*wap* has more commands and options than what has been shown above, and fully documents\nthat usage in its help text. View it with:\n\n.. code-block:: console\n\n  wap --help\n  wap build --help\n  wap upload --help\n  # ... etc\n\nThe *wap* Configuration File\n----------------------------\n\n*wap* only needs one file to operate: a YAML file named ``.wap.yml``.\n\nFor new YAML authors, see `What is YAML? <https://blog.stackpath.com/yaml/>`_.\n\n.. warning::\n  For advanced YAML authors, it may be important to note that *wap* uses a subset of\n  YAML called ``strictyaml``. This provides many benefits for users, but does\n  `restrict some YAML features. <https://hitchdev.com/strictyaml/#design-justifications>`_.\n  There\'s a good chance you won\'t even notice a difference.\n\n.. warning::\n  In *wap* configuration files, all paths are treated as POSIX paths. The main takeaway\n  of this is that path separators (the slashes between directories and subdirectories\n  and files) are **forward slashes** (``/``). By choosing a standard, configuration\n  files become cross-platform.\n\n  .. code-block:: yaml\n\n     path/to/my.lua    # GOOD, only forward slashes\n     path\\to\\my.lua    # bad\n     path/to\\my.lua    # bad\n\nSample Config File and Directory Structure\n******************************************\n\nHere\'s a high-level, commented example of a ``.wap.yml`` file:\n\n.. code-block:: yaml\n\n  # the name of your addon, can be anything you like\n  name: MyAddon\n\n  # a list of versions of WoW your addon works on\n  wow-versions:\n    - 9.0.2\n    - 1.13.6\n\n  # If you want to upload to CurseForge, include this section\n  curseforge:\n    # found on your project page\n    project-id: 123456\n    # change history file\n    changelog: CHANGELOG.md\n    # found from your CurseForge URL\n    # ex: https://www.curseforge.com/wow/addons/myaddon -> "myaddon"\n    addon-name: myaddon\n\n  # a list of directories that will be packaged up\n  dirs:\n    - path: MyDir  # an addon directory\n      toc:  # TOC generation\n        tags:  # metadata about your addon for WoW\n          Title: MyAddon\n          Notes: A great addon for WoW\n          Author: Me\n          X-CustomTag: CustomValue\n        files:  # the files to load, in order, for your addon, as found inside MyDir\n          - Init.lua\n          - MySubDir/Sub.lua\n\nAnd heres a directory structure that this config could work with:\n\n.. code-block::\n\n   MyProject                # your project directory\n   ├── MyDir                # your addon directory (dirs[*].path in config)\n   |   ├── Init.lua         # A Lua code file (dirs[*].toc.files in config)\n   |   └── MySubDir         # A subdirectory in your addon directory\n   │       └── Sub.lua      # Another Lua code file (dirs[*].toc.files in config)\n   ├── CHANGELOG.md         # changelog file (curseforge.changelog in config)\n   ├── README.md            # readme documentation\n   └── .wap.yml             # configuration file\n\nSyntax\n******\n\n``name``\n^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``string``\n\nDescription\n  The name of your packaged addon. This name will be used to name the build directories\n  and zip files for your addon (as well as the zip file users download on CurseForge).\n\n  You can name this anything you want.\n\n``wow-versions``\n^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``sequence``\n\nDescription\n  The versions of World of Warcraft that your addon supports. *wap* will create\n  different builds for each version in the output directory.\n\n  Each version must be in the form "``x.y.z``", where ``x``, ``y``, and ``z`` are\n  non-negative integers.\n\n  You must at least supply one of these, and can at most supply two (for retail and\n  classic).\n\n  *wap* uses these versions for a few things:\n\n  - To properly generate your TOC file with the right ``## Interface`` tag\n  - To mark on CurseForge which version your addon supports\n  - To ``dev-install`` the right build into the right WoW AddOns path. For example a\n    classic addon build should not go into a\n    ``World of Warcraft/_retail_/Interface/AddOns`` directory.\n\n``curseforge``\n^^^^^^^^^^^^^^\n\nRequired\n  No\n\nType\n  ``map``\n\nDescription\n  If you want to upload your project to CurseForge, include this section.\n\n``curseforge.project-id``\n^^^^^^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``string``\n\nDescription\n  The project id as found on your CurseForge addon\'s page. This field tells wap\n  what addon page to upload to.\n\n  .. image:: https://raw.githubusercontent.com/t-mart/wap/master/docs/project-id.png\n    :alt: Where to find your CurseForge project id\n\n``curseforge.changelog``\n^^^^^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``string``\n\nDescription\n  The path *relative to this config file* of your changelog file. This file should\n  contain a helpful history of changes to your addon over time. There are no\n  requirements for the contents of this file -- it just needs to exist. You may leave\n  it blank if you\'re just starting out.\n\n  See the `Sample Config File and Directory Structure`_ section for an example on where\n  this file is expected to be inside your project.\n\n  This field is required because CurseForge requires it. Each file on your Files page\n  is accompanied by a changelog.\n\n  CurseForge aside, maintaining a changelog is a good practice. Not only is this helpful\n  to your users, but it\'s also helpful to your collaborators. It\'s extremely common to\n  see changelog files in source code repositories.\n\n  CurseForge supports three changelog formats:\n\n  - ``markdown``\n  - ``html``\n  - ``text``\n\n  *wap* will try to chose the correct format based on the extension of the file you\n  provide for this field. It does so according to the following mapping:\n\n  +-----------------+-------------------+\n  | File Extension  | ``changelogType`` |\n  +=================+===================+\n  | ``.md``         | ``markdown``      |\n  +-----------------+-------------------+\n  | ``.markdown``   | ``markdown``      |\n  +-----------------+-------------------+\n  | ``.html``       | ``html``          |\n  +-----------------+-------------------+\n  | ``.txt``        | ``text``          |\n  +-----------------+-------------------+\n  | All other cases | ``text``          |\n  +-----------------+-------------------+\n\n``curseforge.addon-name``\n^^^^^^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``string``\n\nDescription\n  The string of the name of your addon as it is found in your addon\'s CurseForge\n  URL.\n\n  While not strictly necessary, this helps *wap* provide better output for you in the\n  form of URLs that you can copy-paste into your browser.\n\n  For example, if your addon\'s URL is\n  ``https://www.curseforge.com/wow/addons/dpsbooster``, then you would use the string\n  ``dpsbooster`` here.\n\n``dirs``\n^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``sequence``\n\nDescription\n  A sequence of directories to include in your packaged addon.\n\n  Many small addons will only contain a single ``dirs`` entry, but more complex ones\n  will have many.\n\n``dirs[*].path``\n^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``string``\n\nDescription\n  The path *relative to this config file* of the directory you\'d like to include in your\n  packaged addon.\n\n  See the `Sample Config File and Directory Structure`_ section for an example on where\n  this directory is expected to be inside your project.\n\n  This cannot be a file -- only directories are installable into WoW addons folders.\n\n``dirs[*].toc``\n^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``map``\n\nDescription\n  A mapping of ``tags`` and ``files`` from which to generate your TOC file.\n\n  For more information on why TOC file generation is a good thing, see\n  `Why generate TOC files?`_.\n\n``dirs[*].toc.tags``\n^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``map``\n\nDescription\n  A mapping of key-value pairs to include in the generated TOC file. The keys and values\n  will be interpreted as strings.\n\n  Use this section to provide things like the ``Title``, ``Notes`` (description), and\n  any other WoW-specified tags. A full list of supported tags may be found at the\n  WoW Gamepedia\n  `TOC format article <https://wow.gamepedia.com/TOC_format#Display_in_the_addon_list>`_.\n  Custom tags can be added too, and should be prefixed with ``X-``.\n\n  To demonstrate, a ``tags`` section that looks like this:\n\n  .. code-block:: yaml\n\n    tags:\n      Title: MyAddon\n      Notes: This is my addon\n      X-Custom-Tag: CustomValue\n\n  will produce a TOC file with this content:\n\n  .. code-block::\n\n    ## Title: MyAddon\n    ## Notes: This is my addon\n    ## X-Custom-Tag: CustomValue\n\n  .. warning::\n    **You should not provide the ``Interface`` and ``Version`` tags!** *wap* generates\n    those tags for you. You can override them, but it is not recommended.\n\n``dirs[*].toc.files``\n^^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``sequence``\n\nDescription\n  A sequence of paths *relative to* `dirs[*].path`_  that specify the Lua (or XML) files\n  your addon should load. The order of this sequence is respected in the generated TOC\n  file.\n\n  See the `Sample Config File and Directory Structure`_ section for an example on where\n  these files are expected to be inside your project.\n\n  To demonstrate, a ``files`` section that looks like this:\n\n  .. code-block:: yaml\n\n    files:\n      - Init.lua\n      - Core.lua\n\n  will produce a TOC file with this content:\n\n  .. code-block::\n\n    Init.lua\n    Core.lua\n\n  Additionally, the files here are validated to ensure they actually exist. File that do\n  not exist almost certainly indicate an bug, so *wap* will abort if such a case is\n  found and print the missing file.\n\nWhy?\n----\n\nWhy make another addon tool?\n****************************\n\n*wap* is a reimagining of how developers create addons. The most popular current\nsolution is probably the `packager <https://github.com/BigWigsMods/packager>`_ project,\nI think there are some design flaws that needed revisiting. Namely, it:\n\n- Encourages the use substitution directives (e.g. ``--@keyword@``) to solve problems,\n  which are:\n\n  * difficult to read, write, and maintain\n  * slow to process (some of my builds take\n    `7+ minutes at this step <https://github.com/t-mart/ItemVersion/runs/1864902187>`_!)\n  * impossible to run `static analysis <https://github.com/mpeterv/luacheck>`_ on\n\n- Conflates for dependencies (``externals``) and source code repositories. They are not\n  the same thing.\n- Presumes your entire repository should be packaged up, which is awkward and\n  heavy-handed for most modern projects and requires ``ignore``-ing many files.\n- Mandates the use of certain version control processes, which are inaccessible for\n  beginning developers.\n- Reads its configuration from several files (``.pkgmeta`` and ``.toc`` files).\n\nWhy not implement substitution directives like ``--@retail@``?\n**************************************************************\n\nLet\'s compare two examples:\n\n**With substitution directives**\n\n.. code-block:: lua\n\n  -- WITH SUBSTITUTION DIRECTIVES\n  local wowVersion = "retail"\n  --[===[@non-retail@\n  local wowVersion = "classic"\n  --@end-non-retail@]===]\n  print("Hi, I\'m running on " .. wowVersion .. " WoW!")\n\nThe above code will built differently for retail and classic builds. This makes it easy\nto introduce bugs because developers have to keep in mind how the code differs in each\ncase. It is no longer Lua code -- it is an overloading of Lua comments into a\npreprocessing language with its own esoteric syntax and keyword names.\n\nAdditionally, you can\'t run static analyzers like\n`luacheck <https://github.com/mpeterv/luacheck>`_ on this code.\n\n**With pure lua code and the WoW API**\n\n.. code-block:: lua\n\n  -- WITH THE WOW API\n  local wowVersion = "retail"\n  if WOW_PROJECT_ID == WOW_PROJECT_CLASSIC then\n    wowVersion = "classic"\n  end\n  print("Hi, I\'m running on " .. wowVersion .. " WoW!")\n\nThis code is clear in its intentions. It\'s simply Lua code, and it leverages the WoW\nAPI we have at hand to do the job. And, it can be statically analyzed.\n\nAnd this is just the Lua. Substitution directives also exist for TOC and XML files:\n\n- The main case for substitution in TOC files is to handle the ``Interface`` tag, which\n  *wap* can do for you.\n- For XML, there may be a valid use case. But, there\'s almost no reason to be writing\n  XML. Lua can do everything that WoW XML can.\n\nIn closing, the main point is here is that there are programmatic ways to do everything\nsubstitution directives do in your Lua code, but in a better way. And TOC file\ngeneration is handled by *wap* itself.\n\nWhy generate TOC files?\n***********************\n\nThere are two main reasons:\n\n- Cut down on duplication. If you need to upload a retail AND a classic version, you\'d\n  otherwise need to create 2 nearly identical TOC files that only differ in their\n  ``Interface`` tags.\n\n  So instead, by centralizing TOC contents into the ``.wap.yml``, *wap* can generate\n  your TOC file with your tags and files AND the correct ``Interface`` for the version\n  of WoW you are targeting.\n\n- TOC validation. *wap* validates that:\n\n  * Any files listed actually exist within that folder\n  * Any custom tags are prefixed with ``X-``, which is necessary for them to be\n    retrievable by\n    `GetAddOnMetadata <https://wowwiki-archive.fandom.com/wiki/API_GetAddOnMetadata>`_.\n\n\nWhy not automatically get my addon\'s version number from my VCS?\n****************************************************************\n\nIn the spirit of keeping *wap* (and addon development in general!) accessible, I don\'t\nwant to force your hand on your addon\'s development process and tooling.\n\nBesides, if you insist, you can extract a version from your VCS and use it as the\nargument to any *wap* commands that accept it.\n\nWhy not support pulling in dependencies (``externals``) from other repositories?\n********************************************************************************\n\nFor a variety of reasons:\n\n- Source code repositories are not releases. That is not their purpose. Source code\n  repositories are filled with all sorts of things like READMEs and ``.gitignore`` files\n  and tests and documentation and the list the goes on and on... And none of that has to\n  do with the Lua code that you\'re really after.\n\n  That Lua code belongs in a deliberate release asset (file/zip/etc) by the project\n  owner, cleansed and packaged in a way you can include in your addon.\n\n  Unfortunately, Lua does not have a distribution format and/or package repository (e.g.\n  PyPI for Python, Maven Central for Java, Docker Hub for Docker, etc). But source\n  code repositories are not the drop-in replacement.\n\n- Even if you do have dependency repository that\'s tolerably clean and packaged in its\n  natural form, that repository is actually a development-time dependency, not a\n  release-time dependency like other addon packagers imply. It needs to be *inside* your\n  codebase while you write your code. Otherwise, you\'re coding on hope.\n\n  * Other addon packagers don\'t even require a commit hash/tag to be specified, so you\n    can\'t even be sure what of what code will be included with your addon in those\n    cases. Dependencies shouldn\'t be changing *at all* unless you\'ve deliberately\n    upgraded them.\n\n- It slows down your release process to redownload dependencies. Pulling them into\n  source code once is much faster.\n\n- Finally, this is just feature bloat for *wap*. It\'s excessive to write a ``git clone``\n  and/or ``svn checkout`` runner when you can run those tools better yourself. It opens\n  up a huge surface area of support if *wap* would need to be able to run those tools\n  itself.\n\nTLDR: *wap* could, but it won\'t. **Copy your dependencies into your project from an\nofficial release of that dependency, or from the its repository if that is all they\noffer.**\n\nWhy not upload WoWInterface too?\n********************************\n\nThe momentum of the WoW community points towards CurseForge.\n\nI actually have written WoWInterface support, but removed it because I don\'t think many\nusers would want it.\n\nIf I\'m wrong about that, please create an issue and we can discuss and reassess.\n\nWhy not upload GitHub Release assets?\n*************************************\n\n- It requires that a tag is exists in the repository, which is a prerequisite for a\n  GitHub release. I don\'t want to force your hand on your development process.\n\n- It adds the GitHub API itself as a dependency, which is a moving target.\n\n- It\'s something that other tools already do better.\n\nInstead, I kindly suggest you incorporate something like\n`Github CLI <https://cli.github.com/>` or\n`upload-release-asset <https://github.com/actions/upload-release-asset>`_ into your\nbuild process in conjunction with *wap* if you want this feature. For *wap*, it\'s too\nmuch bloat for too little gain.\n\nContributing\n------------\n\nSee `CONTRIBUTING.rst <CONTRIBUTING.rst>`_.\n\nTODOs\n-----\n\n- localization via curseforge?\n- Dockerfile\n- Dockerfile github action `<https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action>`_\n',
    'author': 'Tim Martin',
    'author_email': 'tim@timmart.in',
    'maintainer': None,
    'maintainer_email': None,
    'url': 'https://github.com/t-mart/wap',
    'packages': packages,
    'package_data': package_data,
    'install_requires': install_requires,
    'entry_points': entry_points,
    'python_requires': '>=3.9,<4.0',
}


setup(**setup_kwargs)
