{
    "info": {
        "author": "Roy Wright",
        "author_email": "roy@wright.org",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 5 - Production/Stable",
            "Environment :: Console",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: MIT License",
            "Natural Language :: English",
            "Operating System :: MacOS :: MacOS X",
            "Operating System :: POSIX",
            "Operating System :: Unix",
            "Programming Language :: Python :: 2.6",
            "Programming Language :: Python :: 2.7",
            "Programming Language :: Python :: 3.3",
            "Programming Language :: Python :: 3.4",
            "Topic :: Software Development :: Build Tools"
        ],
        "description": "\nWhat is Herring?\n================\n\nHerring is a simple python make utility.  You write tasks in python, and\noptionally assign dependent tasks.  The command line interface lets you easily\nlist the tasks and run them.\n\n\"First you must find... another shrubbery! (dramatic chord) Then, when you have\nfound the shrubbery, you must place it here, beside this shrubbery, only\nslightly higher so you get a two layer effect with a little path running down\nthe middle. (\"A path! A path!\") Then, you must cut down the mightiest tree in\nthe forrest... with... a herring!\"\n\n\nTasks\n=====\n\n\nTask Definition\n---------------\n\nTasks are defined by using a @task decorator on a function definition in the\nproject's herringfile::\n\n    @task()\n    def foo():\n        \"\"\" Do something fooey \"\"\"\n        #...\n\nTask decorators can take optional keywords:\n\n:depends:\n    List of task names as strings that this task depends upon.  All depends tasks will be ran prior to this task.\n    Example a task that depends on tasks \"foo\" and \"bar\" in the same namespace would be declared as:\n    depends=['foo', 'bar'].  A task that depends on a task in another namespace, say task 'bar' in\n    namespace 'foo', would be declared as:  depends['foo::bar'].\n\n:dependent_of:\n    Task name as string that this task is a dependent of.  This allows you to add a dependency to a third party\n    task.  For example, to run a \"predoc\" task before generating documentation using herringlib's \"doc\" task,\n    you would set the \"dependent_of\" task decorator attribute to \"doc::generate\".\n\n:help:\n    Text that will be shown as notes when showing tasks (ex: running \"herring -T\").\n\n:namespace:\n    The namespace for the task.  Examples:  \"alpha\", \"alpha::beta\", \"alpha::beta::charlie\",...\n\n:private:\n    A boolean that can be used to declare a task private.  The default is for each task with a docstring to\n    be public while tasks without a docstring are private.  This flag overrides this behavior making the task\n    private whether or not it has a docstring.\n\n:kwargs:\n    A list of command line arguments recognized by the task.  For example kwargs=['alpha', 'beta'] means\n    the task can accept \"--alpha=foo --beta=bar\" on the herring command line.  This is intended to allow\n    GUI front-ends to build a dialog prompting for the options for the task.\n\n:arg_prompt:\n    If the task requires a command line argument and none are give, use this string to prompt the user for\n    the argument.  The task can access this attribute using: task.arg_prompt\n\n:configured:\n    Indicates if herringfile must be filled in.  If configured is \"no\", then herringfile must be\n    non-existent or empty for the task to be available.  If configured is \"optional\", then the task is always\n    available.  If configure is \"required\" then the task is available if the herringfile is not empty.\n    \"required\" is default.\n\nThis example defines task \"test::bar\" that is dependent on task \"foo\"::\n\n    @task(namespace='test', depends=['foo'], help=\"doesn't do anything\")\n    def bar():\n        \"\"\" The bar for foo \"\"\"\n\nThis example shows prompting for an argument::\n\n    @task(arg_prompt=\"Enter a value:\")\n    def foobar():\n        \"\"\" This foobar needs a value \"\"\"\n        if task.arg_prompt is not None:\n            value = prompt(task.arg_prompt)\n\n\nTask Scopes\n-----------\n\nNormal tasks (with docstrings) are public by default while hidden tasks (without docstrings)\nare private.  You can make a public task private by setting the private attribute to True.\nDeclaring a task private lets you keep the docstring but hide the task from normal task list.\nMore on task scopes later.\n\n\nNamespaces\n----------\n\nNamespaces are a grouping mechanism for tasks, not to be confused with python\nnamespace/packages.  The purpose is so you can easily group related tasks\nwithout using a naming convention.\n\nFor example say you had the following three documentation tasks::\n\n    @task(depends=['doc_generate_icon'])\n    def doc_sphinx():\n        pass\n\n    @task()\n    def doc_generate_icon()\n        pass\n\n    @task(depends=['doc_sphinx'])\n    def doc()\n        pass\n\nUsing namespaces you could have something like::\n\n    with namespace('doc'):\n\n        @task(depends=['doc::generate_icon'])\n        def sphinx():\n            pass\n\n        @task()\n        def generate_icon()\n            pass\n\n    @task(depends=['doc::sphinx'])\n    def doc()\n        pass\n\nNote that you may use multiple namespaces within the same module or even have tasks from different\nmodules in the same namespace.\n\nAlso that namespaces do not affect directly calling a method.  So you may simply call the **generate_icon()**\nmethod directly.  Calling the method directly does not run the task's dependencies.  To run a task with it's\ndependencies, use the **task_execute()** function.  For example::\n\n    task_execute('doc')\n\nwill run the doc::sphinx dependency then the doc() task.\n\nYou may run multiple tasks by giving task_execute a list of tasks::\n\n    task_execute(['generate_icon', 'sphinx'])\n\n\nRunning a Task\n--------------\n\nTo run a task, simply be in the directory with your herringfile or one of it's\nsub-directories and to run the **doc** task, type::\n\n    herring doc\n\nthis will run the **doc::generate_icon** task then the **doc::sphinx** task then the **doc** task.\n\n.. note::\n\n    Herring performs a topological sort on a tasks dependencies.  This generates a list of sets of\n    tasks.  The list is executed in order.  The tasks in each set are executed in parallel\n    processes.  Output (both stdout and stderr) is captured while each task is ran then upon task\n    completion is writen to the output.\n\n    The --interactive flag may be used to prevent the tasks running in parallel.  Instead the tasks\n    in a set are ran in random order without buffering the output.\n\n\nCommand Line Arguments\n----------------------\n\nTo pass arguments to the task, simply place them on the command line as keyword\narguments.  The tasks may access the lists by using::\n\n    task.argv\n\nOr already parsed as keyword args by using::\n\n    task.kwargs\n\n\nFor Example::\n\n    @task()\n    def argDemo():\n        print(\"argv: %s\" % repr(task.argv))\n        print(\"kwargs: %s\" % repr(task.kwargs))\n\n    herring argDemo --delta=3 --flag\n\noutputs::\n\n    argv: ['--delta=3', '--flag']\n    kwargs: ['delta': 3, 'flag': True]\n\n\nAvailable Tasks\n---------------\n\nTo see the list of available tasks, run::\n\n    herring -T\n    Show tasks\n    ============================================================\n    herring foo        # Do something fooey\n    herring bar        # The bar for foo\n\nIf you do not include a docstring for a task, then the task is hidden (private) and will not\nshow up in the list, although it can still be ran.\n\nTo show all tasks, including hidden tasks::\n\n    herring --all\n\n\nReusing Tasks\n-------------\n\nHerring supports loading files from a \"herringlib\" directory.  This can be a single directory\nor the union of several directories.  If the later, then herring will search for directories\nto include in the union in the following order:\n\n1. any directories specified with the command line option --herringlib,\n2. a \"herringlib\" sub-directory to the directory that contains the \"herringfile\" file,\n3. the directory specified in the \"HERRINGLIB\" environment variable,\n4. the \"~/.herring/herringlib\" directory.\n\nThe union is created with the first found directory being the top most.  This means that if the\nsame filename exists in multiple found directories, the version in the first found directory will\nbe used.\n\nTechnically herring will create a temporary directory and copy the contents from the found directories\nin the order found but not overwriting files.  Herring automatically deletes this temporary directory\nunless you tell it not to with the --leave_union_dir flag (sometimes useful for debugging).\n\nThe environment variable approach is good for using a common set of tasks among a group of projects.\nThe sub-directory approach is good for using project specific tasks.\nThe \"~/.herring/herringlib\" approach is good for having your own set of default tasks.\n\nHerring will attempt to load all .py files in the virtual \"herringlib\" directory (glob: \"herringlib/\\*\\*/\\*.py\").\nThese .py files may include tasks just like the herringfile.\n\nYou will probably want to include __init__.py in herringlib and it's sub-directories so\nyou can easily import the modules in your herringfile.\n\nRecommended practice is to group related tasks and support methods in modules in\nthe herringlib directory.  Making these tasks project independent facilitates code\nreuse.  See the *herringlib* project (https://github.com/royw/herringlib) for some\nreusable herring tasks.\n\n\nQuick Project Initialization using herringlib project\n-----------------------------------------------------\n\nHerring with herringlib can initialize a new project with a herringfile and a set of generic\ntasks in the herringlib.  Further this set of generic tasks can populate your\nproject with common infrastructure files.\n\nInstall Herring into your system python::\n\n    \u27a4 sudo pip install Herring\n\nYou can install the herringlib tasks into the project and/or install them for all\nyour projects by clone them into your ~/.herring directory::\n\n    \u27a4 mkdir -p ~/.herring\n    \u27a4 cd ~/.herring\n    \u27a4 git clone https://github.com/royw/herringlib.git\n\nWhile in your ~/.herring directory you may want to create a ~/.herring/herring.conf file with some\ndefaults for your projects.  For example::\n\n    \u27a4 cat ~/.herring/herring.conf\n    [Herring]\n\n    [project]\n    author: Roy Wright\n    author_email: roy.wright@example\n    dist_host: pypi.example.com\n    pypi_path: /var/pypi/dev\n\nThe [Herring] section is for command line options to herring.  The [project] section is for the defaults\nin herringlib's Project object (see the generated herringfile and this will make sense).\n\nHere's an example session showing the quick project initialization.\n\nEither create a new project or start a new one.\n\nChange to the project's directory then create a herringfile::\n\n    \u27a4 touch herringfile\n\nCreate the development environment by running::\n\n    \u27a4 herring project::init\n\nthis will give you a boilerplate herringfile and populate the project with support for package building, documentation,\na MVC commandline application.\n\n.. note::\n\n    Project::init will provide a CLI application boilerplate code in the Project.package directory.  On\n    existing projects you probably want to delete these.\n\nEdit your herringfile, mainly verifying or changing the dictionary values being passed to Project.metadata().\n\n.. note::\n\n    The first time that you run herring after a project::init, more templates are installed using the metadata\n    in your herringfile.  So it is very important to edit your herringfile **immediately** after running\n    project::init.\n\nTo see all settings with their current values::\n\n    \u27a4 herring project::describe\n\nNow you can create the virtual environments for your project with:\n\n    \u27a4 herring project::mkvenvs\n\n.. note::\n\n    Herringlib supports multiple virtual environments intended for supporting multiple python versions.  The virtual\n    environments will be named by concatenating the **package** with each of the **python_versions** values.  For\n    example, if the herringfile's metadata contained::\n\n        Project.metadata(\n        {\n            'package': 'foo',       # snakecase\n            'python_versions': ('35', '34', '27'),\n        }\n\n    then the following virtual environments would be created::\n\n        foo35\n        foo34\n        foo27\n\n    The other \\*_version and \\*_versions metadata select which virtual environments will be used in certain circumstances.\n    For example::\n\n        'test_python_versions': ('27', '35'),\n\n    will cause \"herring test\" to run the test task twice, once using the foo27 virtualenv and again using foo35.\n\n\nFinally you are ready to develop your project.  The following are typical command flow::\n\n    \u27a4 herring test\n    \u27a4 herring version::bump\n    \u27a4 git add -A\n    \u27a4 git commit -m 'blah...'\n    \u27a4 herring doc\n    \u27a4 herring build\n    \u27a4 herring deploy doc::publish\n\nTo see a list of public tasks:\n\n    \u27a4 herring -T\n\n",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://herring.example.com",
        "keywords": "",
        "license": "license.txt",
        "maintainer": "",
        "maintainer_email": "",
        "name": "Herring",
        "package_url": "https://pypi.org/project/Herring/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/Herring/",
        "project_urls": {
            "Homepage": "http://herring.example.com"
        },
        "release_url": "https://pypi.org/project/Herring/0.1.49/",
        "requires_dist": null,
        "requires_python": "",
        "summary": "Just a python make utility.",
        "version": "0.1.49"
    },
    "last_serial": 2621180,
    "releases": {
        "0.1.49": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "81dc4a5b13d3db327bee9ce68c86ec30",
                    "sha256": "07de82a49d0ba830a979f09aa3dd7ef2ba7b11b8309a447231cc59e377bc52c1"
                },
                "downloads": -1,
                "filename": "Herring-0.1.49.tar.gz",
                "has_sig": false,
                "md5_digest": "81dc4a5b13d3db327bee9ce68c86ec30",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 43078,
                "upload_time": "2017-02-05T21:51:36",
                "url": "https://files.pythonhosted.org/packages/5d/52/81b24ed4ce85e900df5d2cf83acf5c601ebceef362157212fac71c53b3b8/Herring-0.1.49.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "81dc4a5b13d3db327bee9ce68c86ec30",
                "sha256": "07de82a49d0ba830a979f09aa3dd7ef2ba7b11b8309a447231cc59e377bc52c1"
            },
            "downloads": -1,
            "filename": "Herring-0.1.49.tar.gz",
            "has_sig": false,
            "md5_digest": "81dc4a5b13d3db327bee9ce68c86ec30",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 43078,
            "upload_time": "2017-02-05T21:51:36",
            "url": "https://files.pythonhosted.org/packages/5d/52/81b24ed4ce85e900df5d2cf83acf5c601ebceef362157212fac71c53b3b8/Herring-0.1.49.tar.gz"
        }
    ]
}