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

package_dir = \
{'': 'src'}

packages = \
['dj', 'dj.choicee']

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

install_requires = \
['django>=2.0']

setup_kwargs = {
    'name': 'dj.choicee',
    'version': '0.9.1',
    'description': 'An enum implementation for Django field choices, supporting group',
    'long_description': '==========\ndj.choicee\n==========\n\n.. image:: https://badgen.net/pypi/v/dj.choicee\n   :target: https://pypi.org/project/dj.choicee\n.. image:: https://travis-ci.org/AgriConnect/dj.choicee.png\n  :target: https://travis-ci.org/AgriConnect/dj.choicee\n\nThis is a much clearer way to specify choices for fields in models and forms.\nA basic example:\n\n.. code-block:: python\n\n    >>> from dj.choicee import Choices\n    >>> class Gender(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   male = _("Male")\n    ...   female = _("Female")\n    ...\n    >>> Gender()\n    [(1, \'Male\'), (2, \'Female\')]\n    >>> Gender.male\n    <Choice: male (id: 1)>\n    >>> Gender.female\n    <Choice: female (id: 2)>\n    >>> Gender.male.id\n    1\n    >>> Gender.male.desc\n    \'Male\'\n    >>> Gender.male.raw\n    \'Male\'\n    >>> Gender.male.name\n    \'male\'\n    >>> Gender.from_name("male")\n    <Choice: male (id: 1)>\n    >>> Gender.id_from_name("male")\n    1\n    >>> Gender.raw_from_name("male")\n    \'Male\'\n    >>> Gender.desc_from_name("male")\n    \'Male\'\n    >>> Gender.name_from_id(2)\n    \'female\'\n    >>> Gender.name_from_id(3)\n    Traceback (most recent call last):\n    ...\n    ValueError: Nothing found for \'3\'.\n    >>> Gender.from_name("perez")\n    Traceback (most recent call last):\n    ...\n    ValueError: Nothing found for \'perez\'.\n\nYou define a class of choices, specifying each choice as a class attribute.\nThose attributes are ``int`` subclasses, numbered automatically starting with\n1.  The class provides several features which support the DRY principle:\n\n * An object instantiated from the choices class is basically a list of ``(id,\n   localized_description)`` pairs straight for consumption by Django.\n\n * Each attribute defined can be retrieved directly from the class.\n\n * Metadata (e.g. attribute name, raw and localized description, numeric ID) of\n   each attribute is accessible.\n\n * Choices which are suffixed by ``_`` to avoid clashing with Python keywords\n   have this suffix automatically removed in their ``.name`` attributes\n\n * Lookup functions are available to help getting attributes or their metadata.\n\n..  note::\n    The ``_ = Choices.Choice`` trick makes it possible for ``django-admin.py\n    makemessages`` to find each choice description and include it in ``.po``\n    files for localization.  It masks ``gettext`` only in the scope of the class so\n    the rest of the module can safely use ``gettext`` or ``gettext_lazy``.  Having to\n    specify ``_`` each time is not a particularly pretty solution but it\'s\n    explicit. Suggestions for a better approach are welcome.\n\nGrouping choices\n----------------\n\nOne of the worst problems with choices is their weak extensibility.  For\ninstance, an application defines a group of possible choices like this:\n\n.. code-block:: python\n\n    >>> class License(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   gpl = _("GPL")\n    ...   bsd = _("BSD")\n    ...   proprietary = _("Proprietary")\n    ...\n    >>> License()\n    [(1, \'GPL\'), (2, \'BSD\'), (3, \'Proprietary\')]\n\nAll is well until the application goes live and after a while the developer\nwants to include LGPL.  The natural choice would be to add it after ``gpl`` but\nwhen we do that, the indexing would break.  On the other hand, adding the new\nentry at the end of the definition looks ugly and makes the resulting combo\nboxes in the UI sorted in a counter-intuitive way.  Grouping lets us solve this\nproblem by explicitly defining the structure within a class of choices:\n\n.. code-block:: python\n\n    >>> class License(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   COPYLEFT = Choices.Group(0)\n    ...   gpl = _("GPL")\n    ...\n    ...   PUBLIC_DOMAIN = Choices.Group(100)\n    ...   bsd = _("BSD")\n    ...\n    ...   OSS = Choices.Group(200)\n    ...   apache2 = _("Apache 2")\n    ...\n    ...   COMMERCIAL = Choices.Group(300)\n    ...   proprietary = _("Proprietary")\n    ...\n    >>> License()\n    [(1, \'GPL\'), (101, \'BSD\'), (201, \'Apache 2\'), (301, \'Proprietary\')]\n\nThis enables the developer to include more licenses of each group later on:\n\n.. code-block:: python\n\n    >>> class License(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   COPYLEFT = Choices.Group(0)\n    ...   gpl_any = _("GPL, any")\n    ...   gpl2 = _("GPL 2")\n    ...   gpl3 = _("GPL 3")\n    ...   lgpl = _("LGPL")\n    ...   agpl = _("Affero GPL")\n    ...\n    ...   PUBLIC_DOMAIN = Choices.Group(100)\n    ...   bsd = _("BSD")\n    ...   public_domain = _("Public domain")\n    ...\n    ...   OSS = Choices.Group(200)\n    ...   apache2 = _("Apache 2")\n    ...   mozilla = _("MPL")\n    ...\n    ...   COMMERCIAL = Choices.Group(300)\n    ...   proprietary = _("Proprietary")\n    ...\n    >>> License()\n    [(1, \'GPL, any\'), (2, \'GPL 2\'), (3, \'GPL 3\'), (4, \'LGPL\'),\n     (5, \'Affero GPL\'), (101, \'BSD\'), (102, \'Public domain\'),\n     (201, \'Apache 2\'), (202, \'MPL\'), (301, \'Proprietary\')]\n\nNote the behaviour:\n\n * the developer renamed the GPL choice but its meaning and ID remained stable\n\n * BSD, Apache and proprietary choices have their IDs unchanged\n\n * the resulting class is self-descriptive, readable and extensible\n\nAs a bonus, the explicitly specified groups can be used when needed:\n\n.. code-block:: python\n\n    >>> License.COPYLEFT\n    <ChoiceGroup: COPYLEFT (id: 0)>\n    >>> License.gpl2 in License.COPYLEFT.choices\n    True\n    >>> [(c.id, c.desc) for c in License.COPYLEFT.choices]\n    [(1, \'GPL, any\'), (2, \'GPL 2\'), (3, \'GPL 3\'), (4, \'LGPL\'),\n     (5, \'Affero GPL\')]\n\n``ChoiceField``\n---------------\n\nChoices can be used with generic ``IntegerField`` and ``CharField`` instances.\nWhen you do that though, some minor API deficiencies show up fairly quickly.\nFirst, when you define the field, you have to instanciate the choices class and\nthe default value has to be converted to the proper type explicitly:\n\n.. code-block:: python\n\n    color = models.IntegerField(choices=Color(), default=Color.green.id)\n\nSecond, when getting the attribute back from a model, it has to be converted to\na ``Choice`` instance to do anything interesting with it:\n\n.. code-block:: python\n\n    >>> obj = Model.objects.get(pk=3)\n    >>> obj.color\n    3\n    >>> Color.from_id(obj.color)\n    <Choice: Blue (id: 3, name: blue)>\n\nTo overcome those problems a ``ChoiceField`` is available in the\n``dj.choicee.fields`` package.  It is based on integers on the database level but\nthe API exposes ``Choice`` instances.  This helps both on the definition side:\n\n.. code-block:: python\n\n    color = ChoiceField(choices=Color, default=Color.green)\n\nand on the access side:\n\n.. code-block:: python\n\n    >>> obj = Model.objects.get(pk=3)\n    >>> obj.color\n    <Choice: Blue (id: 3, name: blue)>\n    >>> obj.color = Color.green\n    >>> obj.save()\n    >>> Model.objects.get(pk=3).color\n    <Choice: Green (id: 2, name: green)>\n\nFor rendering forms, the field coerces to integer values.  That also means that\nwherever ``Choice`` instances are accepted, integers are also fine.\n\nAdvanced functionality\n----------------------\n\nFiltering\n~~~~~~~~~\n\nThe developer can specify all possible choices for future use and then filter\nout only the currently applicable values on choices creation:\n\n.. code-block:: python\n\n    >>> class Language(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   de = _("German")\n    ...   en = _("English")\n    ...   fr = _("French")\n    ...   pl = _("Polish")\n    ...\n    >>> Language()\n    [(1, \'German\'), (2, \'English\'), (3, \'French\'), (4, \'Polish\')]\n    >>> Language(filter=("en", "pl"))\n    [(2, \'English\'), (4, \'Polish\')]\n\nThis has the great advantage of keeping the IDs and sorting intact.\n\nCustom item format\n~~~~~~~~~~~~~~~~~~\n\nOne can also change how the pairs are constructed by providing a factory\nfunction.  For instance, to use the class of choices defined above for the\n``LANGUAGES`` setting in ``settings.py``, one could specify:\n\n.. code-block:: python\n\n    >>> Language(item=lambda choice: (choice.name, choice.raw))\n    [(\'de\', \'German\'), (\'en\', \'English\'), (\'fr\', \'French\'),\n     (\'pl\', \'Polish\')]\n\nExtra attributes on choices\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nEach choice can receive extra arguments using the ``extra()`` method:\n\n.. code-block:: python\n\n    >>> class Python(Choices):\n    ...   _ = Choices.Choice\n    ...\n    ...   cpython = _("CPython").extra(language=\'C\')\n    ...   pypy = _("PyPy").extra(language=\'Python\')\n    ...   jython = _("Jython").extra(language=\'Java\')\n    ...   iron_python = _("IronPython").extra(language=\'C#\')\n\nThis adds a ``language`` attribute to each choice so you can get it back like\nthis:\n\n.. code-block:: python\n\n    >>> Python.jython.language\n    \'Java\'\n\nThis enables polymorphic attribute access later on when using models or forms.\nFor instance, suppose you have a simple model like:\n\n.. code-block:: python\n\n    >>> class Library(models.Model):\n    ...   name = models.CharField(max_length=100)\n    ...   python_kind = models.IntegerField(choices=Python(), default=Python.cpython.id)\n\nIn that case to get the implementation language back yo\'d do:\n\n.. code-block:: python\n\n    >>> library = Library.objects.get(name=\'dj.choicee\')\n    >>> Python.from_id(library.python_kind).language\n    \'C\'\n\nThat frees your user code of any conditionals or dictionaries that depend on the\nstate of the choices class.  If you would add another choice to it, no user code\nneeds to be changed to support it.  This also supports the DRY principle because\nthe choices class becomes the single place where configuration of that kind is\nheld.\n\nExtra attributes on choice groups\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nUnsurprisingly, choice groups can have extra attributes as well.  They are then\ninherited by choices in such a group and can be overriden if necessary.  For\ninstance:\n\n.. code-block:: python\n\n  >>> class ProfileChange(Choices):\n  ...   _ = Choices.Choice\n  ...\n  ...   USER = Choices.Group(0).extra(icon=\'bookkeeping.png\', is_public=True)\n  ...   email = _("e-mail").extra(is_public=False)\n  ...   first_name = _("first name")\n  ...   last_name = _("last name")\n  ...\n  ...   BASIC_INFO = Choices.Group(10).extra(icon=\'bookkeeping.png\', is_public=True)\n  ...   birth_date = _("birth date").extra(icon=\'calendar.png\')\n  ...   gender = _("gender").extra(icon=\'male_female.png\')\n  ...   country = _("country")\n  ...   city = _("city")\n  ...\n  ...   CONTACT_INFO = Choices.Group(20).extra(icon=\'contactbook.png\', is_public=False)\n  ...   skype = _("Skype ID")\n  ...   icq = _("ICQ number")\n  ...   msn = _("MSN login")\n  ...   xfire = _("X-Fire login")\n  ...   irc = _("IRC info").extra(is_public=True)\n\nIn that case proper inheritance takes place:\n\n.. code-block:: python\n\n  >>> ProfileChange.first_name.is_public\n  True\n  >>> ProfileChange.email.is_public\n  False\n  >>> ProfileChange.country.icon\n  \'bookkeeping.png\'\n  >>> ProfileChange.birth_date.icon\n  \'calendar.png\'\n\n\nPredefined choices\n------------------\n\nThere are several classes of choices which are very common in web applications\nso they are provided already: ``Country``, ``Gender`` and ``Language``.\n\nHow do I run the tests?\n-----------------------\n\nInstall `tox <https://pypi.org/project/tox/>`_ then run:\n\n.. code-block:: sh\n\n  $ tox -e py\n\nChange Log\n----------\n\n1.0.0\n~~~~~\n\n* Pure Python 3 (drop Python 2 compatibility).\n* Support only Python3.5+ and Django 2.0+\n* Fork from `dj.choices`_ to new project.\n\nAuthors\n-------\n\n- Original `dj.choices`_ author `Łukasz Langa <mailto:lukasz@langa.pl>`_.\n- Fork and drop legacy Python2 code: `Nguyễn Hồng Quân <ng.hong.quan@gmail.com>`_.\n\n\n.. _dj.choices: https://pypi.org/project/dj.choices/\n',
    'author': 'Nguyễn Hồng Quân',
    'author_email': 'ng.hong.quan@gmail.com',
    'maintainer': 'Nguyễn Hồng Quân',
    'maintainer_email': 'ng.hong.quan@gmail.com',
    'url': 'https://github.com/AgriConnect/dj.choicee',
    'package_dir': package_dir,
    'packages': packages,
    'package_data': package_data,
    'install_requires': install_requires,
    'python_requires': '>=3.5',
}


setup(**setup_kwargs)
