{
    "info": {
        "author": "Maximilian Maahn",
        "author_email": "maximilian.maahn@colorado.edu",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 3 - Alpha",
            "Environment :: Console",
            "Intended Audience :: Science/Research",
            "License :: OSI Approved :: MIT License",
            "Operating System :: OS Independent",
            "Programming Language :: Python",
            "Topic :: Scientific/Engineering"
        ],
        "description": "## meteo_si\n<!-- [![Build Status](https://travis-ci.org/uwescience/meteo_si.svg?branch=master)](https://travis-ci.org/uwescience/meteo_si) -->\n\n[![Documentation Status](https://readthedocs.org/projects/meteo-si/badge/?version=latest)](https://meteo-si.readthedocs.io/en/latest/?badge=latest)\n\nMeteo SI is a collection of functions for atmospheric sciences following the \nSI-convention (unless stated otherwise). See \nhttps://meteo-si.readthedocs.io/en/latest/ for documentation. \n\n<!-- ### Module code\n\nWe place the module code in a file called `meteo_si.py` in directory called\n`meteo_si`. This structure is a bit confusing at first, but it is a simple way\nto create a structure where when we type `import meteo_si as sb` in an\ninteractive Python session, the classes and functions defined inside of the\n`meteo_si.py` file are available in the `sb` namespace. For this to work, we\nneed to also create a file in `__init__.py` which contains code that imports\neverything in that file into the namespace of the project:\n\n    from .meteo_si import *\n\nIn the module code, we follow the convention that all functions are either\nimported from other places, or are defined in lines that precede the lines that\nuse that function. This helps readability of the code, because you know that if\nyou see some name, the definition of that name will appear earlier in the file,\neither as a function/variable definition, or as an import from some other module\nor package.\n\nIn the case of the meteo_si module, the main classes defined at the bottom of\nthe file make use of some of the functions defined in preceding lines.\n\nRemember that code will be probably be read more times than it will be written.\nMake it easy to read (for others, but also for yourself when you come back to\nit), by following a consistent formatting style. We strongly recommend\nfollowing the\n[PEP8 code formatting standard](https://www.python.org/dev/peps/pep-0008/), and\nwe enforce this by running a code-linter called\n[`flake8`](http://flake8.pycqa.org/en/latest/), which automatically checks the\ncode and reports any violations of the PEP8 standard (and checks for other\n  general code hygiene issues), see below.\n\n### Project Data\n\nIn this case, the project data is rather small, and recorded in csv\nfiles.  Thus, it can be stored alongside the module code.  Even if the\ndata that you are analyzing is too large, and cannot be effectively\ntracked with github, you might still want to store some data for\ntesting purposes.\n\nEither way, you can create a `meteo_si/data` folder in which you can\norganize the data. As you can see in the test scripts, and in the\nanalysis scripts, this provides a standard file-system location for\nthe data at:\n\n    import os.path as op\n    import meteo_si as sb\n    data_path = op.join(sb.__path__[0], 'data')\n\n\n### Testing\n\nMost scientists who write software constantly test their code. That is, if you\nare a scientist writing software, I am sure that you have tried to see how well\nyour code works by running every new function you write, examining the inputs\nand the outputs of the function, to see if the code runs properly (without\nerror), and to see whether the results make sense.\n\nAutomated code testing takes this informal practice, makes it formal, and\nautomates it, so that you can make sure that your code does what it is supposed\nto do, even as you go about making changes around it.\n\nMost scientists writing code are not really in a position to write a complete\n[specification](http://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/)\nof their software, because when they start writing their code they don't quite\nknow what they will discover in their data, and these chance discoveries might\naffect how the software evolves. Nor do most scientists have the inclination to\nwrite complete specs - scientific code often needs to be good enough to cover\nour use-case, and not any possible use-case. Testing the code serves as a way to\nprovide a reader of the code with very rough specification, in the sense that it\nat least specifies certain input/output relationships that will certainly hold\nin your code.\n\nWe recommend using the ['pytest'](http://pytest.org/latest/) library for\ntesting. The `py.test` application traverses the directory tree in which it is\nissued, looking for files with the names that match the pattern `test_*.py`\n(typically, something like our `meteo_si/tests/test_meteo_si.py`). Within each\nof these files, it looks for functions with names that match the pattern\n`test_*`. Typically each function in the module would have a corresponding test\n(e.g. `test_transform_data`). This is sometimes called 'unit testing', because\nit independently tests each atomic unit in the software. Other tests might run a\nmore elaborate sequence of functions ('end-to-end testing' if you run through\nthe entire analysis), and check that particular values in the code evaluate to\nthe same values over time. This is sometimes called 'regression testing'. We\nhave one such test in `meteo_si/tests/test_meteo_si.py` called\n`test_params_regression`. Regressions in the code are often canaries in the coal\nmine, telling you that you need to examine changes in your software\ndependencies, the platform on which you are running your software, etc.\n\nTest functions should contain assertion statements that check certain relations\nin the code. Most typically, they will test for equality between an explicit\ncalculation of some kind and a return of some function. For example, in the\n`test_cumgauss` function, we test that our implmentation of the cumulative\nGaussian function evaluates at the mean minus 1 standard deviation to\napproximately (1-0.68)/2, which is the theoretical value this calculation should\nhave. We recommend using functions from the `numpy.testing` module (which we\nimport as `npt`) to assert certain relations on arrays and floating point\nnumbers. This is because `npt` contains functions that are specialized for\nhandling `numpy` arrays, and they allow to specify the tolerance of the\ncomparison through the `decimal` key-word argument.\n\nTo run the tests on the command line, change your present working directory to\nthe top-level directory of the repository (e.g. `/Users/arokem/code/meteo_si`),\nand type:\n\n    py.test meteo_si\n\nThis will exercise all of the tests in your code directory. If a test fails, you\nwill see a message such as:\n\n\n    meteo_si/tests/test_meteo_si.py .F...\n\n    =================================== FAILURES ===================================\n    ________________________________ test_cum_gauss ________________________________\n\n      def test_cum_gauss():\n          sigma = 1\n          mu = 0\n          x = np.linspace(-1, 1, 12)\n          y = sb.cumgauss(x, mu, sigma)\n          # A basic test that the input and output have the same shape:\n          npt.assert_equal(y.shape, x.shape)\n          # The function evaluated over items symmetrical about mu should be\n          # symmetrical relative to 0 and 1:\n          npt.assert_equal(y[0], 1 - y[-1])\n          # Approximately 68% of the Gaussian distribution is in mu +/- sigma, so\n          # the value of the cumulative Gaussian at mu - sigma should be\n          # approximately equal to (1 - 0.68/2). Note the low precision!\n    >       npt.assert_almost_equal(y[0], (1 - 0.68) / 2, decimal=3)\n    E       AssertionError:\n    E       Arrays are not almost equal to 3 decimals\n    E        ACTUAL: 0.15865525393145707\n    E        DESIRED: 0.15999999999999998\n\n    meteo_si/tests/test_meteo_si.py:49: AssertionError\n    ====================== 1 failed, 4 passed in 0.82 seconds ======================\n\nThis indicates to you that a test has failed. In this case, the calculation is\naccurate up to 2 decimal places, but not beyond, so the `decimal` key-word\nargument needs to be adjusted (or the calculation needs to be made more\naccurate).\n\nAs your code grows and becomes more complicated, you might develop new features\nthat interact with your old features in all kinds of unexpected and surprising\nways. As you develop new features of your code, keep running the tests, to make\nsure that you haven't broken the old features.  Keep writing new tests for your\nnew code, and recording these tests in your testing scripts. That way, you can\nbe confident that even as the software grows, it still keeps doing correctly at\nleast the few things that are codified in the tests.\n\nWe have also provided a `Makefile` that allows you to run the tests with more\nverbose and informative output from the top-level directory, by issuing the\nfollowing from the command line:\n\n    make test\n\n### Styling\n\nIt is a good idea to follow the PEP8 standard for code formatting. Common code\nformatting makes code more readable, and using tools such as `flake8` (which\ncombines the tools `pep8` and `pyflakes`) can help make your code more readable,\navoid extraneous imports and lines of code, and overall keep a clean project\ncode-base.\n\nSome projects include `flake8` inside their automated tests, so that every pull\nrequest is examined for code cleanliness.\n\nIn this project, we have run `flake8` most (but not all) files, on\nmost (but not all) checks:\n\n```\nflake8 --ignore N802,N806 `find . -name *.py | grep -v setup.py | grep -v /doc/`\n```\n\nThis means, check all .py files, but exclude setup.py and everything in\ndirectories named \"doc\". Do all checks except N802 and N806, which enforce\nlowercase-only names for variables and functions.\n\nThe `Makefile` contains an instruction for running this command as well:\n\n    make flake8\n\n### Documentation\n\nDocumenting your software is a good idea. Not only as a way to communicate to\nothers about how to use the software, but also as a way of reminding yourself\nwhat the issues are that you faced, and how you dealt with them, in a few\nmonths/years, when you return to look at the code.\n\nThe first step in this direction is to document every function in your module\ncode. We recommend following the [numpy docstring\nstandard](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt),\nwhich specifies in detail the inputs/outputs of every function, and specifies\nhow to document additional details, such as references to scientific articles,\nnotes about the mathematics behind the implementation, etc.\n\nThis standard also plays well with a system that allows you to create more\ncomprehensive documentation of your project. Writing such documentation allows\nyou to provide more elaborate explanations of the decisions you made when you\nwere developing the software, as well as provide some examples of usage,\nexplanations of the relevant scientific concepts, and references to the relevant\nliterature.\n\nTo document `meteo_si` we use the [sphinx documentation\nsystem](http://sphinx-doc.org/). You can follow the instructions on the sphinx\nwebsite, and the example [here](http://matplotlib.org/sampledoc/) to set up the\nsystem, but we have also already initialized and commited a skeleton\ndocumentation system in the `docs` directory, that you can build upon.\n\nSphinx uses a `Makefile` to build different outputs of your documentation. For\nexample, if you want to generate the HTML rendering of the documentation (web\npages that you can upload to a website to explain the software), you will type:\n\n\tmake html\n\nThis will generate a set of static webpages in the `doc/_build/html`, which you\ncan then upload to a website of your choice.\n\nAlternatively, [readthedocs.org](https://readthedocs.org) (careful,\n*not* readthedocs.**com**) is a service that will run sphinx for you,\nand upload the documentation to their website. To use this service,\nyou will need to register with RTD. After you have done that, you will\nneed to \"import your project\" from your github account, through the\nRTD web interface. To make things run smoothly, you also will need to\ngo to the \"admin\" panel of the project on RTD, and navigate into the\n\"advanced settings\" so that you can tell it that your Python\nconfiguration file is in `doc/conf.py`:\n\n![RTD conf](https://github.com/uwescience/meteo_si/blob/master/doc/_static/RTD-advanced-conf.png)\n\n http://meteo_si.readthedocs.org/en/latest/\n\n\n### Installation\n\nFor installation and distribution we will use the python standard\nlibrary `distutils` module. This module uses a `setup.py` file to\nfigure out how to install your software on a particular system. For a\nsmall project such as this one, managing installation of the software\nmodules and the data is rather simple.\n\nA `meteo_si/version.py` contains all of the information needed for the\ninstallation and for setting up the [PyPI\npage](https://pypi.python.org/pypi/meteo_si) for the software. This\nalso makes it possible to install your software with using `pip` and\n`easy_install`, which are package managers for Python software. The\n`setup.py` file reads this information from there and passes it to the\n`setup` function which takes care of the rest.\n\nMuch more information on packaging Python software can be found in the\n[Hitchhiker's guide to\npackaging](https://the-hitchhikers-guide-to-packaging.readthedocs.org).\n\n\n### Continuous integration\n\nTravis-CI is a system that can be used to automatically test every revision of\nyour code directly from github, including testing of github pull requests,\nbefore they are merged into the `master` branch. This provides you with\ninformation needed in order to evaluate contrubutions made by others. It also\nserves as a source of information for others interested in using or contributing\nto your project about the degree of test coverage of your project.\n\nYou will need a .travis.yml file in your repo. This file contains the\nconfiguration of your testing environment. This includes the different\nenvironments in which you will test the source code (for example, we test\n`meteo_si` against Python 2.7, Python 3.3 and Python 3.4). It includes steps\nthat need to be taken before installation of the software. For example,\ninstallation of the software dependencies. For `meteo_si`, we use the\n[`Miniconda`](http://conda.pydata.org/miniconda.html) software distribution (not\nto be confused with [`Anaconda`](https://store.continuum.io/cshop/anaconda/),\nthough they are similar and both produced by Continuum).\n\nFor details on setting up Travis-CI with github, see Travis-CI's\n[getting started\npage](https://docs.travis-ci.com/user/getting-started/#To-get-started-with-Travis-CI%3A). To\nsummarize:\n\nFirst, go to the Travis-CI [website](https://travis-ci.org/) and get a\nTravis user account, linked to your github user account.\n\nYou will need to set up your github repo to talk to Travis (More explanation +\npictures will come here).\n\nYou will need to go back to travis-ci, and flip on the switch on that side as\nwell.\n\nThe travis output will also report to you about test coverage, if you set it up\nthat way.\n\nYou will start getting emails telling you the state of the testing suite on\nevery pull request for the software, and also when you break the test suite on\nthe `master` branch. That way, you can be pretty sure that the `master` is\nworking (or at least know when it isn't...).\n\nYou can also continuously test your code on a Windows system. This is done on\nanother CI system called [Appveyor](http://www.appveyor.com/). In prinicple, it\ndoes something that is very similar to what Travis does: downloads your code,\ninstalls it on a Windows machine, with various versions of python, and runs the\ntests. Appveyor is controlled through another configuration file: the\n`appveyor.yml`. In addition to committing this file into the repository, you\nwill need to activate Appveyor for your project. This is done by signing into\nthe Appveyor interface with your Github account, clicking on the \"projects\" tab\nat the top of the page, then clicking on the \"+\" sign for \"New project\" and\nselecting the project you would like to add from the menu that appears (you\nmight need to give Appveyor the permission to see projects in your Github\naccount).\n\n### Distribution\n\nThe main venue for distribution of Python software is the [Python\nPackage Index](https://pypi.python.org/), or PyPI, also lovingly known\nas \"the cheese-shop\".\n\nTo distribute your software on PyPI, you will need to create a user account on\n[PyPI](http://python-packaging-user-guide.readthedocs.org/en/latest/distributing/#register-your-project).\nIt is recommended that you upload your software using\n[twine](http://python-packaging-user-guide.readthedocs.org/en/latest/distributing/#upload-your-distributions).\n\nUsing Travis, you can automatically upload your software to PyPI,\nevery time you push a tag of your software to github. The instructions\non setting this up can be found\n[here](http://docs.travis-ci.com/user/deployment/pypi/). You will need\nto install the travis command-line interface\n\n### Licensing\n\nLicense your code! A repository like this without a license maintains\ncopyright to the author, but does not provide others with any\nconditions under which they can use the software. In this case, we use\nthe MIT license. You can read the conditions of the license in the\n`LICENSE` file. As you can see, this is not an Apple software license\nagreement (has anyone ever actually tried to read one of those?). It's\nactually all quite simple, and boils down to \"You can do whatever you\nwant with my software, but I take no responsibility for what you do\nwith my software\"\n\nFor more details on what you need to think about when considering\nchoosing a license, see this\n[article](http://www.astrobetter.com/blog/2014/03/10/the-whys-and-hows-of-licensing-scientific-code/)!\n\n### Getting cited\n\nWhen others use your code in their research, they should probably cite you. To\nmake their life easier, we use [duecredit](http://www.duecredit.org). This is a software\nlibrary that allows you to annotate your code with the correct way to cite it.\nTo enable `duecredit`, we have added a file `due.py` into the main directory.\nThis file does not need to change at all (though you might want to occasionally\nupdate it from duecredit itself. It's\n[here](https://github.com/duecredit/duecredit/blob/master/duecredit/stub.py),\nunder the name `stub.py`).\n\nIn addition, you will want to provide a digital object identifier (DOI) to the\narticle you want people to cite.\n\nTo get a DOI, use the instructions in [this page](https://guides.github.com/activities/citable-code/)\n\nAnother way to get your software cited is by writing a paper. There are several\n[journals that publish papers about software](https://www.software.ac.uk/resources/guides/which-journals-should-i-publish-my-software).\n\n### Scripts\n\nA scripts directory can be used as a place to experiment with your\nmodule code, and as a place to produce scripts that contain a\nnarrative structure, demonstrating the use of the code, or producing\nscientific results from your code and your data and telling a story\nwith these elements.\n\nFor example, this repository contains an [IPython notebook] that reads\nin some data, and creates a figure. Maybe this is *Figure 1* from some\nfuture article? You can see this notebook fully rendered\n[here](https://github.com/uwescience/meteo_si/blob/master/scripts/Figure1.ipynb).\n\n\n### Git Configuration\n\nCurrently there are two files in the repository which help working\nwith this repository, and which you could extend further:\n\n- `.gitignore` -- specifies intentionally untracked files (such as\n  compiled `*.pyc` files), which should not typically be committed to\n  git (see `man gitignore`)\n- `.mailmap` -- if any of the contributors used multiple names/email\n  addresses or his git commit identity is just an alias, you could\n  specify the ultimate name/email(s) for each contributor, so such\n  commands as `git shortlog -sn` could take them into account (see\n  `git shortlog --help`)\n\n\n### Using `meteo_si` as a template\n\nLet's assume that you want to create a small scientific Python project\ncalled `smallish`. Maybe you already have some code that you are\ninterested in plugging into the module file, and some ideas about what\nthe tests might look like.\n\nTo use this repository as a template, you can use the Github import\nfunctionality. Go to [https://import.github.com](https://import.github.com).\nUnder \"old repository clone URL\" enter: https://github.com/uwescience/meteo_si\n\nUnder \"new repository details\" enter in the name field the name of your\nproject. For example, enter `smallish` here. After that, you can hit the \"Begin\nImport\" button.\n\nYou should then be able to clone the new repo into your machine. You will want\nto change the names of the files. For example, you will want to move\n`meteo_si/meteo_si.py` to be called `smallish/smallish.py`\n\n\tgit mv meteo_si smallish\n\tgit mv smallish/meteo_si.py smallish/smallish.py\n\tgit mv smallish/tests/test_meteo_si.py smallish/tests/test_smallish.py\n\nMake a commit recording these changes. Something like:\n\n\tgit commit -a -m\"Moved names from `meteo_si` to `smallish`\"\n\nYou will probably want to remove all the example data:\n\n\tgit rm smallish/data/*\n\tgit commit -a -m\"Removed example `meteo_si` data\"\n\nPossibly, you will want to add some of your own data in there.\n\nYou will want to edit a few more places that still have `meteo_si` in them. Type\nthe following to see where all these files are:\n\n\tgit grep meteo_si\n\nYou can replace `meteo_si` for `smallish` quickly with:\n\n\tgit grep -l 'meteo_si' | xargs sed -i 's/meteo_si/smallish/g'\n\nThis very file (README.md) should be edited to reflect what your project is\nabout.\n\nOther places that contain this name include the `doc/conf.py` file, which\nconfigures the sphinx documentation, as well as the `doc/Makefile` file (edit\ncarefully!), and the `doc/index.rst` file.\n\nThe `.coveragerc` file contains a few mentions of that name, as well as the\n`.travis.yml` file. This one will also have to be edited to reflect your PyPI\ncredentials (see [above](### Distribution)).\n\nEdit all the mentions of `meteo_si` in the `meteo_si/__init__.py` file, and in\nthe `meteo_si/version.py` file as well.\n\nFinally, you will probably want to change the copyright holder in the `LICENSE`\nfile to be you. You can also replace the text of that file, if it doesn't match\nyour needs.\n\nAt this point, make another commit, and continue to develop your own code based\non this template.\n -->\n\n",
        "description_content_type": "text/markdown",
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://github.com/maahn/meteo_si",
        "keywords": "",
        "license": "MIT",
        "maintainer": "Maximilian Maahn",
        "maintainer_email": "maximilian.maahn@colorado.edu",
        "name": "meteo-si",
        "package_url": "https://pypi.org/project/meteo-si/",
        "platform": "OS Independent",
        "project_url": "https://pypi.org/project/meteo-si/",
        "project_urls": {
            "Homepage": "http://github.com/maahn/meteo_si"
        },
        "release_url": "https://pypi.org/project/meteo-si/0.1.1.dev0/",
        "requires_dist": [
            "numpy"
        ],
        "requires_python": "",
        "summary": "meteo_si: Meteo SI is a collection of meteorological formulas",
        "version": "0.1.1.dev0"
    },
    "last_serial": 3885358,
    "releases": {
        "0.1.1.dev0": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "6cefd472c8fd8917d57dfeedebd46d31",
                    "sha256": "08a013a7478207977c3dffec642b8f4fdd947a14ba96feb48d7d9de8a810791f"
                },
                "downloads": -1,
                "filename": "meteo_si-0.1.1.dev0-py3-none-any.whl",
                "has_sig": false,
                "md5_digest": "6cefd472c8fd8917d57dfeedebd46d31",
                "packagetype": "bdist_wheel",
                "python_version": "py3",
                "requires_python": null,
                "size": 19163,
                "upload_time": "2018-05-21T23:59:33",
                "url": "https://files.pythonhosted.org/packages/33/68/a46a53b859beb91b1bafcbc12102a7b5fe8010013f5522daddf025bb2202/meteo_si-0.1.1.dev0-py3-none-any.whl"
            },
            {
                "comment_text": "",
                "digests": {
                    "md5": "613a7364769a43efe546988f80330061",
                    "sha256": "904cf266e5d1ac4220b9b8c55ed043d74f8c9bb1382e9cfe1370db2b16f402b9"
                },
                "downloads": -1,
                "filename": "meteo_si-0.1.1.dev0.tar.gz",
                "has_sig": false,
                "md5_digest": "613a7364769a43efe546988f80330061",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 17953,
                "upload_time": "2018-05-21T23:59:34",
                "url": "https://files.pythonhosted.org/packages/92/ab/1a061efc98e918d1a76e94603c02f9c0888951d899edba22bc02f7ae936b/meteo_si-0.1.1.dev0.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "6cefd472c8fd8917d57dfeedebd46d31",
                "sha256": "08a013a7478207977c3dffec642b8f4fdd947a14ba96feb48d7d9de8a810791f"
            },
            "downloads": -1,
            "filename": "meteo_si-0.1.1.dev0-py3-none-any.whl",
            "has_sig": false,
            "md5_digest": "6cefd472c8fd8917d57dfeedebd46d31",
            "packagetype": "bdist_wheel",
            "python_version": "py3",
            "requires_python": null,
            "size": 19163,
            "upload_time": "2018-05-21T23:59:33",
            "url": "https://files.pythonhosted.org/packages/33/68/a46a53b859beb91b1bafcbc12102a7b5fe8010013f5522daddf025bb2202/meteo_si-0.1.1.dev0-py3-none-any.whl"
        },
        {
            "comment_text": "",
            "digests": {
                "md5": "613a7364769a43efe546988f80330061",
                "sha256": "904cf266e5d1ac4220b9b8c55ed043d74f8c9bb1382e9cfe1370db2b16f402b9"
            },
            "downloads": -1,
            "filename": "meteo_si-0.1.1.dev0.tar.gz",
            "has_sig": false,
            "md5_digest": "613a7364769a43efe546988f80330061",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 17953,
            "upload_time": "2018-05-21T23:59:34",
            "url": "https://files.pythonhosted.org/packages/92/ab/1a061efc98e918d1a76e94603c02f9c0888951d899edba22bc02f7ae936b/meteo_si-0.1.1.dev0.tar.gz"
        }
    ]
}