{
    "info": {
        "author": "Matthew Martin",
        "author_email": "matthewdeanmartin@gmail.com",
        "bugtrack_url": null,
        "classifiers": [
            "Programming Language :: Python",
            "Programming Language :: Python :: 2.7",
            "Programming Language :: Python :: 3.5",
            "Programming Language :: Python :: 3.6",
            "Programming Language :: Python :: Implementation :: CPython",
            "Programming Language :: Python :: Implementation :: PyPy"
        ],
        "description": "jiggle_version\n==============\n\nOpinionated, no config build version incrementer. No regex. Drop in and\ngo.\n\n::\n\n    pip install jiggle_library\n\n    cd src\n    # should run from same folder with setup.py\n    # or parent folder of my_module/__init__.py\n\n    jiggle_library here\n    # find, bump & update version strings in source code\n\n    jiggle_version here --module=my_module\n    # specify which module.\n\n    git --tag $(jiggle_library find)\n\nDepends on cmp-version, docopt, parver, semantic-version, versio, which\nyour application is unlikely to depend on.\n\nProblem to be solved\n--------------------\n\nThere are up to 1/2 dozen places to update a version string. You scoff,\n\u2018Can\u2019t be!\u2019 But for a mature code base, it is because so many tools\nexpect version strings in different places:\n\n-  \\__init__.py has \\__version_\\_\n-  so does \\__version__.py\n-  so does the setup function in setup.py\n-  so does the setup.cfg if you are doing config driven setup.py\n-  your git repo might need a tag matching the library version\n-  you might need a plain text version.txt\n\nYou will need to find the current version, bump the most minor part-\nwhich varies depending on if you are using pep440, semantic version or\nsomething else, update all the places where you could update and re-do\nthis as often as each build and at least as often as each package and\npush to pypi.\n\nOpinionated\n-----------\n\nA library should have one working, no-options, no questions asked\nscenario, e.g.\n\n::\n\n    jiggle_library here\n    # find, bump & update version strings in source code\n\nAn opinionated library has an opinion about the right way to do it. That\nsaid, if the library can discover existing conventions, it should\ndiscover them and use them. If you don\u2019t like it, see the end for\ncompeting opinionated libraries and their philosophy, such as\nvcs-tag-only, regex-more-regex-all-day-regex.\n\nThe following contraints enable \u201cdrop in and go\u201d\n\nNo Config, No Regex\n-------------------\n\nIf the config is more complex than re-writing the code from scratch,\nthere is something wrong with a library.\n\nDon\u2019t contaminate the package\n-----------------------------\n\nOther than creating \\__init__.py, \\__version__.py, etc, no code should\ncontaminate the users setup.py, nor package folder. No code should have\nto run in \\__version__.py or the like, for example, nothing like\n``__version__ = run_git_command_to_find_version()``, it should be equal\nto a constant.\n\nThe use of jiggle_version should not increase the number of\ndependencies. (Not yet achieved- vendorizing a library isn\u2019t trivial)\n\nProvide a vendorization option\n------------------------------\n\nIt should be an effortless & license-compatible way to just copy this\nnext to setup.py.\n\nThis isn\u2019t achieved yet. Python-world doesn\u2019t seem to have anything\nsimilar to JS minification or bundling.\n\nDon\u2019t do too many things unrelated to versioning\n------------------------------------------------\n\nDon\u2019t run tests, create manifests, create a package, force checkins &\ntags, etc.\n\nProvide a multiple interfaces\n-----------------------------\n\nA build tool shouldn\u2019t assume any particular build system.\n\n-  *Bash:* Command line - e.g. ``jiggle_version here``\n-  *python*: import - e.g.\n   ``import jiggle_version; jiggle_version.go()``\n-  *setup.py*: plugin - e.g. \u2018setup.py jiggle_version\u2019, e.g.\n\n   setup_requires=[\u2018jiggle_version\u2019], use_jiggle_version=True,\n\nor\n\n::\n\n    cmdclass=jiggle_version_command, # not yet implemented\n\nDon\u2019t argue over a patch version\n--------------------------------\n\nIf multiple versions are detected, but are close, e.g.\u00a01.2.3 and 1.2.4,\njust use 1.2.4. This is the most common real world sync problem.\n\nDon\u2019t force the developer to create irrelevant things\n-----------------------------------------------------\n\nFor example, if there is no README.md, don\u2019t make me create one.\n\nDon\u2019t update natural language files\n-----------------------------------\n\nThere is no way to do this without programming-like configuration. Your\nREADME.md might say, \u201cIn versions 0.1.0 there were bugs and in 2.0.0\nthey were fixed.\u201d There is no way to update that string with a\nzero-config app.\n\nDon\u2019t execute anything at post-deployment runtime\n-------------------------------------------------\n\nNothing succeeds as reliably as assigning a constant.\n\nNo matter how clever or well tested your code is, executing code as\npost-deployment runtime is an additional dependency and failure point.\n\n``__version__.py``:\n\n::\n\n    version = query_pyi()\n    version = query_package_metadata()\n    version = search_for_and_read_text_or_config()\n\nAutomatically Bump \u201cMinor\u201d/\u201cPath\u201d/\u201cBuild\u201d, let user manually update \u201cMajor\u201d\n---------------------------------------------------------------------------\n\nIt should be uncommon to need record a big version change. You can do\nthat manually. It would require AI to bump anything but the patch/build\nnumber.\n\n-  Major - The change is big.\n-  Minor - The change breaks compatibility. This might be detectable\n   with a unit test runner, or maybe even by detecting changes to public\n   interfaces (not that such a concept exists in python) but otherwise\n   is too hard for machines.\n-  Patch - This is the small number that increases each build.\n   jiggle_version *only* solves the problem of incrementing this number.\n\nFiles Targeted\n--------------\n\nTODO: any file with a ``__version__`` attribute. This is usally \u201csingle\nfile\u201d modules and possibly submodules.\n\n/__init__.py - ``__version__ = \"1.1.1\"``\n\nOther source files with version: ``__about__.py',``\\ **meta**.py\u2019,\n\u2019_version.py\u2019 and ``__version__.py`` which I have a problem with.\n\nI don\u2019t think ``__version__.py`` is any sort of standard and it makes\nfor confusing imports, since in an app with a file and attribute named\n``__version__`` you could easily confuse the two.\n\nversion.txt - Some tools put/expect just the version string here. It\nworks well with bash & doesn\u2019t require a parser of any sort.\n\n/setup.cfg\n\n::\n\n    [metadata] \n    version=1.1.1\n\nIf setup.py exists, setup.cfg is created.\n\n``__init__.py`` can\u2019t be created without making a breaking changes, so\nit isn\u2019t created, only updated.\n\nWe make no particular effort to parse wild text. If your current number\nis so messed up that you need regex to ID it, then edit it by hand.",
        "description_content_type": "",
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://github.com/matthewdeanmartin/jiggle_version",
        "keywords": "version,build tools",
        "license": "MIT",
        "maintainer": "",
        "maintainer_email": "",
        "name": "jiggle-version",
        "package_url": "https://pypi.org/project/jiggle-version/",
        "platform": "",
        "project_url": "https://pypi.org/project/jiggle-version/",
        "project_urls": {
            "Homepage": "https://github.com/matthewdeanmartin/jiggle_version"
        },
        "release_url": "https://pypi.org/project/jiggle-version/1.0.68/",
        "requires_dist": null,
        "requires_python": "",
        "summary": "Opinionated, no config build version incrementer. No regex. Drop in and go.",
        "version": "1.0.68"
    },
    "last_serial": 4686516,
    "releases": {
        "1.0.68": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "60e9e8c41dd2c81e9d3c91bba84db40c",
                    "sha256": "2ca1680a0c2e8f89831fea4b8ae6cc7c7eb1524eaff6a100ff1288ad17670bed"
                },
                "downloads": -1,
                "filename": "jiggle_version-1.0.68.tar.gz",
                "has_sig": false,
                "md5_digest": "60e9e8c41dd2c81e9d3c91bba84db40c",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 35835,
                "upload_time": "2019-01-11T18:12:08",
                "url": "https://files.pythonhosted.org/packages/f9/9f/fb263b4a6231d49985316b9ac8675155c49419fd0cab9fb52c409a084f32/jiggle_version-1.0.68.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "60e9e8c41dd2c81e9d3c91bba84db40c",
                "sha256": "2ca1680a0c2e8f89831fea4b8ae6cc7c7eb1524eaff6a100ff1288ad17670bed"
            },
            "downloads": -1,
            "filename": "jiggle_version-1.0.68.tar.gz",
            "has_sig": false,
            "md5_digest": "60e9e8c41dd2c81e9d3c91bba84db40c",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 35835,
            "upload_time": "2019-01-11T18:12:08",
            "url": "https://files.pythonhosted.org/packages/f9/9f/fb263b4a6231d49985316b9ac8675155c49419fd0cab9fb52c409a084f32/jiggle_version-1.0.68.tar.gz"
        }
    ]
}