# -*- 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.0',
    'description': 'A tool that builds your World of Warcraft addon and uploads them to CurseForge',
    '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- Builds and uploads your addons to CurseForge\n- Uploads for retail and/or classic\n- Installs your addons to your Addons folder for fast development feedback\n- Generates valid TOC files for you\n- New project command to get started quickly\n- Is easily configurable\n- Tested on Windows, macOS, and Linux\n\n.. contents:: Table of Contents\n\nUsage\n-----\n\nCreate a new addon project\n**************************\n\nIf you\'d like to get started quickly, create a new project fast with:\n\n.. code-block:: sh\n\n  wap quickstart MyAddon\n\n  # replace MyAddon with whatever you\'d like\n\nThe above command will create a project directory structure like the following:\n\n.. code-block::\n\n  MyAddon               (your project\'s root directory)\n  ├── MyAddon           (an addon directory that can be build/installed/uploaded)\n  │   └── MyAddon.lua   (a Lua code file)\n  ├── CHANGELOG.md      (where you describe changes over time to your project)\n  ├── README.md         (where you document your project)\n  └── .wap.yml          (the *wap* config file)\n\nAfter this, you can begin developing your addon and using other *wap* commands.\n\nMigrating from other pacakgers / Creating a new config file in an existing project\n**********************************************************************************\n\nThe only file *wap* needs to run is a ``.wap.yml`` file. To create a new  file, run:\n\n.. code-block:: sh\n\n  wap new-config\n\nThe generated config file will contain a basic structure to get you started.\n\nThere are a few differences between how *wap* works and how other package managers work.\nPlease read around this document to learn about them.\n\nBuilding\n********\n\nTo build your addon into a single directory (with optional TOC generation) and create a\nzip archive of it, run:\n\n.. code-block:: sh\n\n  wap build\n\nUploading\n*********\n\nTo upload your addon to CurseForge, run:\n\n.. code-block:: sh\n\n  wap upload --addon-version 1.2.3 --curseforge-token "abc123"\n\nInstead of providing ``--curseforge-token``, you may also set the environment variable\n``WAP_CURSEFORGE_TOKEN``.\n\nYou may generate a new token at `<https://authors.curseforge.com/account/api-tokens>`_.\n\nSome may prefer to use the current Git tag name as the version. You can just leverage\nyour shell to fill this option in with something like:\n\n.. code-block:: sh\n\n  wap upload \\\n    --version "$(git describe --always --tags)" \\\n    --release-type release \\\n    --curseforge-token "abc123"\n\nDeveloper Install\n*****************\n\nTo quickly test your addons out on your local WoW installation, run:\n\n.. code-block:: sh\n\n  wap dev-install --wow-addons-path "/path/to/WoW/_retail_/Interface/AddOns"\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\nInstead of providing ``--wow-addons-path``, you may also set the environment variable\n``WAP_WOW_ADDONS_PATH``.\n\nFurther Help\n************\n\nThe *wap* command has more options than what has been shown above, and fully documents\nthat usage in its help text. View it with:\n\n.. code-block:: sh\n\n  wap --help\n  wap build --help\n  wap upload --help\n  # ... etc\n\nInstallation\n------------\n\n1. Get Python 3.9 or greater. You can confirm this with ``python --version`` and\n   verifying your version is at least that.\n\n   You can download Python from `<https://www.python.org/downloads/>`_.\n\n2. Install *wap* from PyPI:\n\n   .. code-block:: sh\n\n     pip install wow-addon-packager\n\n3. Verify *wap* can run:\n\n   .. code-block:: sh\n\n     wap --version\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\n"`Learn YAML in five minutes. <https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes>`_".\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  **The vast majority of users will not notice a difference!**\n\n.. warning::\n  In *wap* configuration files, all paths are treated as POSIX paths. The main highlight\n  of this is that **all path separators (the slashes between directories and **\n  **subdirectories and files) must be FORWARD SLASHES.** By choosing a standard,\n  configuration files become cross-platform.\n\n  All other paths, such as options to the ``wap`` command or outputs of ``wap`` are\n  otherwise unaffected by this rule.\n\nSample ``.wap.yml`` Config File\n*******************************\n\nHere\'s a high-level, commented overview of a ``.wap.yml`` file:\n\n.. code-block:: yaml\n\n  # the name of your addon\n  name: MyAddon\n\n  # the 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\n  curseforge:\n    project-id: 123456  # found on your project page\n    changelog: CHANGELOG.md  # a file relative to this config file with recent changes\n    addon-name: myaddon  # found from your CurseForge URL\n\n  # the contents of my addon\n  dirs:\n    - path: MyAddon  # a directory relative to this config file\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          DefaultState: Enabled\n          LoadOnDemand: 0\n          Dependencies: AnotherAddon\n          X-My-Metadata-Tag: foo\n        files:  # the files to load, in order, for your addon\n          - Init.lua\n          - Core.lua\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:\n\n  - To name the build directories for your addon\n  - To name the ``.zip`` files of your addon as they appear on your system and on\n    Curseforge.\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 targets. *wap* will create different\n  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  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 ``dev-install` the right build into the right WoW AddOns path (e.g. a classic\n    addon build should not go into a ``World of Warcraft/_retail_/Interface/AddOns``\n    directory.\n  - To designate which version your addon supports on CurseForge\n\n  *wap* uses simple heuristics to decide if a version is retail or classic. Conversely,\n  it cannot determine if a version actually exists or not.\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.\n\n  .. image:: 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 the config file* of your changelog file. This file should\n  contain a helpful history of changes to your addon over time. (There are no strict\n  requirements for the contents of this file, but it must exist. You may leave it\n  blank if you wish, but it will not help your users.)\n\n  CurseForge requires changelog contents to be provided with file uploads, and will\n  display this content on the file\'s page.\n\n  The extension of this file is used to determine what ``changelogType`` to provide in\n  the upload request, which is also required. CurseForge currently supports three types:\n\n  - ``markdown``\n  - ``html``\n  - ``text``\n\n  *wap* will try to chose the correct ``changelogType`` based on the extension of the\n  file you provide here. 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, if this is not provided, *wap* cannot provide a URL for\n  your uploads in its output. (This is a limitation of the CurseForge API. *wap* cannot\n  retrieve this name for you.)\n\n  For example, if your addon\'s URL is\n  ``https://www.curseforge.com/wow/addons/myaddon``, then you would use the string\n  ``myaddon`` 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  This cannot be a file -- it must be a directory because WoW only recognizes\n  addons in their own directories in ``Interface/AddOns``.\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\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\n  will produce a TOC file with this content:\n\n  .. code-block::\n\n    ## Title: MyAddon\n    ## Notes: This is my addon\n\n  **Importantly, you do not need to provide the ``Interface`` and ``Version`` tags!**\n  *wap* can generate these for you from the WoW version you specified in\n  ``wow-versions[*].version`` and the version your supply when you ``wap upload``.\n  If you do provide these tags, *wap* will do as you say, but will emit a warning and\n  likely break some of its guarantees.\n\n  You may add custom tags here too, if you wish. Custom tags may be retrieved with the\n  |GetAddOnMetadata function|_, but only if they are prefixed with ``X-``. *wap* will\n  emit a warning about custom tags without this prefix.\n\n  .. |GetAddOnMetadata function| replace:: ``GetAddOnMetadata`` function\n  .. _GetAddOnMetadata function: https://wow.gamepedia.com/API_GetAddOnMetadata\n\n``dirs[*].toc.files``\n^^^^^^^^^^^^^^^^^^^^^\n\nRequired\n  Yes\n\nType\n  ``sequence``\n\nDescription\n  An sequence of paths *relative to the* ``path`` *of this directory* that specify the\n  Lua (or XML) files your addon should load. The order of this sequence is respected.\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 in this space is probably the\n`BigWigsMods/packager <https://github.com/BigWigsMods/packager>`_ project. While I do\nthink they\'ve done some excellent work (and I think they are just improving on prior\nconventions), there are some pain points:\n\n- Substitution directives (e.g. ``--@keyword@``) 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- Dependencies (``externals``) should not be source code repositories\n\n- The complexity of the program has outgrown the Bash scripting language and is\n  therefore difficult to read, write and maintain.\n\nWhy not implement/support substitution directives like ``--@retail@``?\n*************************************************************************\n\nLet\'s compare two examples, one using substitution directives and one using the WoW API:\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\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\nWith substitution directives, I see:\n\n- Lua code comments overloaded into another language with its own special syntax and\n  keyword names.\n- The ability to introduce bugs in the lua code itself, because lua static analyzers\n  like `luacheck <https://github.com/mpeterv/luacheck>`_ obviously do not try to parse\n  comments.\n\nOn the other hand, with the WoW API version, I see:\n\n- Clear, parseable Lua code that can be statically analyzed.\n- A leveraging of the API that WoW exposes.\n\nAnd this is just 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 I\'d counter that you should not be writing\n  it for your addons because WoW Lua code can do everything that WoW XML documents can.\n  So why would you want to put yourself through that?\n\nIn closing, the main point is here is that there are programmatic ways in your Lua code\nto do everything that substitution directives do, 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. *wap* also does this for the ``Version`` tag (the version of\n  your addon), which is passed in as a command line argument when you run *wap*.\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    Non-prefixed tags do not cause an error for WoW, but on the other hand, they are\n    also invisible to WoW.\n\nDuring early development, *optional* TOC generation was considered. But, it was\nultimately disallowed for the following reasons:\n\n- *wap* would do no validation of the tags and files in your TOC file. For example, you\n  may include a file that does not exist or include a custom tag without the ``X-``\n  prefix. This would likely cause bugs.\n- *wap* would not add your ``## Version: <version>`` tag. Therefore:\n\n  * The version in your TOC file will **not** necessarily be equal to the\n    ``--addon-version`` that you supply with commands.\n  * The version may not even exist in your TOC file, which is not an error, but is\n    a very unconventional software practice.\n\n- *wap* would not add your ``## Interface: <interface>`` tag. Again, it may not even\n  exist in your TOC file, which will probably cause WoW to believe it is out-of-date.\n- If you\'re uploading a classic and a retail version, but are using a fixed TOC file in\n  the directories that are zipped, then the classic and retail zip files will be\n  identical. CurseForge specifically identifies this case and will reject one of the\n  uploads after processing it.\n\nSo, TOC generation is probably a good thing. If you encounter a case where the *wap* TOC\ngeneration is insufficient for what you are trying to do, please create an issue.\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 using a command like the\nuploading_ section suggests.\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). Maybe you are\n  lucky and the author of your dependency has created a GitHub Release asset that would\n  serve you better than the repository itself.\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.\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* needs to be able to run those tools itself.\n\nTLDR: *wap* could, but it won\'t. **Copy your dependencies into your project from an\nofficial release, or from the dependency\'s repository if that is all they offer.**\n\nWhy not support WoWInterface uploads?\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 support GitHub Release uploads?\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 requires *wap* to interact with your Git repository, which would include at the\n  very least:\n\n  * knowing Git compatible versions\n\n  * requiring *wap* to be run from within the addon repository, or adding another\n    command line option to specify it.\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- gh actions\n   * mypy\n   * lint?\n   * test\n   * coverage upload\n   * pip release on tag\n- badges for readme\n- little gif that shows how it works\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)
