Initial commit

.coveragerc

+# .coveragerc to control coverage.py
+[run]
+branch = True
+source = swe2hs
+# omit = bad_file.py
+
+[paths]
+source =
+    src/
+    */site-packages/
+
+[report]
+# Regexes for lines to exclude from consideration
+exclude_lines =
+    # Have to re-enable the standard pragma
+    pragma: no cover
+
+    # Don't complain about missing debug-only code:
+    def __repr__
+    if self\.debug
+
+    # Don't complain if tests don't hit defensive assertion code:
+    raise AssertionError
+    raise NotImplementedError
+
+    # Don't complain if non-runnable code isn't run:
+    if 0:
+    if __name__ == .__main__.:

.gitignore

+# Temporary and binary files
+*~
+*.py[cod]
+*.so
+*.cfg
+!.isort.cfg
+!setup.cfg
+*.orig
+*.log
+*.pot
+__pycache__/*
+.cache/*
+.*.swp
+*/.ipynb_checkpoints/*
+.DS_Store
+
+# Project files
+.ropeproject
+.project
+.pydevproject
+.settings
+.idea
+.vscode
+tags
+
+# Package files
+*.egg
+*.eggs/
+.installed.cfg
+*.egg-info
+
+# Unittest and coverage
+htmlcov/*
+.coverage
+.coverage.*
+.tox
+junit*.xml
+coverage.xml
+.pytest_cache/
+
+# Build and docs folder/files
+build/*
+dist/*
+sdist/*
+docs/api/*
+docs/_rst/*
+docs/_build/*
+cover/*
+MANIFEST
+
+# Per-project virtualenvs
+.venv*/
+.conda*/

.readthedocs.yml

+# Read the Docs configuration file
+# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
+
+# Required
+version: 2
+
+# Build documentation in the docs/ directory with Sphinx
+sphinx:
+  configuration: docs/conf.py
+
+# Build documentation with MkDocs
+#mkdocs:
+#  configuration: mkdocs.yml
+
+# Optionally build your docs in additional formats such as PDF
+formats:
+  - pdf
+
+python:
+  version: 3.8
+  install:
+    - requirements: docs/requirements.txt
+    - {path: ., method: pip}

AUTHORS.rst

+============
+Contributors
+============
+
+* Johannes Aschauer <johannes.aschauer@slf.ch>

CHANGELOG.rst

+=========
+Changelog
+=========
+
+Version 0.1
+===========
+
+- Feature A added
+- FIX: nasty bug #1729 fixed
+- add your changes here!

CONTRIBUTING.rst

+.. todo:: THIS IS SUPPOSED TO BE AN EXAMPLE. MODIFY IT ACCORDING TO YOUR NEEDS!
+
+   The document assumes you are using a source repository service that promotes a
+   contribution model similar to `GitHub's fork and pull request workflow`_.
+   While this is true for the majority of services (like GitHub, GitLab,
+   BitBucket), it might not be the case for private repositories (e.g., when
+   using Gerrit).
+
+   Also notice that the code examples might refer to GitHub URLs or the text
+   might use GitHub specific terminology (e.g., *Pull Request* instead of *Merge
+   Request*).
+
+   Please make sure to check the document having these assumptions in mind
+   and update things accordingly.
+
+.. todo:: Provide the correct links/replacements at the bottom of the document.
+
+.. todo:: You might want to have a look on `PyScaffold's contributor's guide`_,
+
+   especially if your project is open source. The text should be very similar to
+   this template, but there are a few extra contents that you might decide to
+   also include, like mentioning labels of your issue tracker or automated
+   releases.
+
+
+============
+Contributing
+============
+
+Welcome to ``swe2hs`` contributor's guide.
+
+This document focuses on getting any potential contributor familiarized
+with the development processes, but `other kinds of contributions`_ are also
+appreciated.
+
+If you are new to using git_ or have never collaborated in a project previously,
+please have a look at `contribution-guide.org`_. Other resources are also
+listed in the excellent `guide created by FreeCodeCamp`_ [#contrib1]_.
+
+Please notice, all users and contributors are expected to be **open,
+considerate, reasonable, and respectful**. When in doubt, `Python Software
+Foundation's Code of Conduct`_ is a good reference in terms of behavior
+guidelines.
+
+
+Issue Reports
+=============
+
+If you experience bugs or general issues with ``swe2hs``, please have a look
+on the `issue tracker`_. If you don't see anything useful there, please feel
+free to fire an issue report.
+
+.. tip::
+   Please don't forget to include the closed issues in your search.
+   Sometimes a solution was already reported, and the problem is considered
+   **solved**.
+
+New issue reports should include information about your programming environment
+(e.g., operating system, Python version) and steps to reproduce the problem.
+Please try also to simplify the reproduction steps to a very minimal example
+that still illustrates the problem you are facing. By removing other factors,
+you help us to identify the root cause of the issue.
+
+
+Documentation Improvements
+==========================
+
+You can help improve ``swe2hs`` docs by making them more readable and coherent, or
+by adding missing information and correcting mistakes.
+
+``swe2hs`` documentation uses Sphinx_ as its main documentation compiler.
+This means that the docs are kept in the same repository as the project code, and
+that any documentation update is done in the same way was a code contribution.
+
+.. todo:: Don't forget to mention which markup language you are using.
+
+    e.g.,  reStructuredText_ or CommonMark_ with MyST_ extensions.
+
+.. todo:: If your project is hosted on GitHub, you can also mention the following tip:
+
+   .. tip::
+      Please notice that the `GitHub web interface`_ provides a quick way of
+      propose changes in ``swe2hs``'s files. While this mechanism can
+      be tricky for normal code contributions, it works perfectly fine for
+      contributing to the docs, and can be quite handy.
+
+      If you are interested in trying this method out, please navigate to
+      the ``docs`` folder in the source repository_, find which file you
+      would like to propose changes and click in the little pencil icon at the
+      top, to open `GitHub's code editor`_. Once you finish editing the file,
+      please write a message in the form at the bottom of the page describing
+      which changes have you made and what are the motivations behind them and
+      submit your proposal.
+
+When working on documentation changes in your local machine, you can
+compile them using |tox|_::
+
+    tox -e docs
+
+and use Python's built-in web server for a preview in your web browser
+(``http://localhost:8000``)::
+
+    python3 -m http.server --directory 'docs/_build/html'
+
+
+Code Contributions
+==================
+
+.. todo:: Please include a reference or explanation about the internals of the project.
+
+   An architecture description, design principles or at least a summary of the
+   main concepts will make it easy for potential contributors to get started
+   quickly.
+
+Submit an issue
+---------------
+
+Before you work on any non-trivial code contribution it's best to first create
+a report in the `issue tracker`_ to start a discussion on the subject.
+This often provides additional considerations and avoids unnecessary work.
+
+Create an environment
+---------------------
+
+Before you start coding, we recommend creating an isolated `virtual
+environment`_ to avoid any problems with your installed Python packages.
+This can easily be done via either |virtualenv|_::
+
+    virtualenv <PATH TO VENV>
+    source <PATH TO VENV>/bin/activate
+
+or Miniconda_::
+
+    conda create -n swe2hs python=3 six virtualenv pytest pytest-cov
+    conda activate swe2hs
+
+Clone the repository
+--------------------
+
+#. Create an user account on |the repository service| if you do not already have one.
+#. Fork the project repository_: click on the *Fork* button near the top of the
+   page. This creates a copy of the code under your account on |the repository service|.
+#. Clone this copy to your local disk::
+
+    git clone git@github.com:YourLogin/swe2hs.git
+    cd swe2hs
+
+#. You should run::
+
+    pip install -U pip setuptools -e .
+
+   to be able to import the package under development in the Python REPL.
+
+   .. todo:: if you are not using pre-commit, please remove the following item:
+
+#. Install |pre-commit|_::
+
+    pip install pre-commit
+    pre-commit install
+
+   ``swe2hs`` comes with a lot of hooks configured to automatically help the
+   developer to check the code being written.
+
+Implement your changes
+----------------------
+
+#. Create a branch to hold your changes::
+
+    git checkout -b my-feature
+
+   and start making changes. Never work on the main branch!
+
+#. Start your work on this branch. Don't forget to add docstrings_ to new
+   functions, modules and classes, especially if they are part of public APIs.
+
+#. Add yourself to the list of contributors in ``AUTHORS.rst``.
+
+#. When you’re done editing, do::
+
+    git add <MODIFIED FILES>
+    git commit
+
+   to record your changes in git_.
+
+   .. todo:: if you are not using pre-commit, please remove the following item:
+
+   Please make sure to see the validation messages from |pre-commit|_ and fix
+   any eventual issues.
+   This should automatically use flake8_/black_ to check/fix the code style
+   in a way that is compatible with the project.
+
+   .. important:: Don't forget to add unit tests and documentation in case your
+      contribution adds an additional feature and is not just a bugfix.
+
+      Moreover, writing a `descriptive commit message`_ is highly recommended.
+      In case of doubt, you can check the commit history with::
+
+         git log --graph --decorate --pretty=oneline --abbrev-commit --all
+
+      to look for recurring communication patterns.
+
+#. Please check that your changes don't break any unit tests with::
+
+    tox
+
+   (after having installed |tox|_ with ``pip install tox`` or ``pipx``).
+
+   You can also use |tox|_ to run several other pre-configured tasks in the
+   repository. Try ``tox -av`` to see a list of the available checks.
+
+Submit your contribution
+------------------------
+
+#. If everything works fine, push your local branch to |the repository service| with::
+
+    git push -u origin my-feature
+
+#. Go to the web page of your fork and click |contribute button|
+   to send your changes for review.
+
+   .. todo:: if you are using GitHub, you can uncomment the following paragraph
+
+      Find more detailed information in `creating a PR`_. You might also want to open
+      the PR as a draft first and mark it as ready for review after the feedbacks
+      from the continuous integration (CI) system or any required fixes.
+
+
+Troubleshooting
+---------------
+
+The following tips can be used when facing problems to build or test the
+package:
+
+#. Make sure to fetch all the tags from the upstream repository_.
+   The command ``git describe --abbrev=0 --tags`` should return the version you
+   are expecting. If you are trying to run CI scripts in a fork repository,
+   make sure to push all the tags.
+   You can also try to remove all the egg files or the complete egg folder, i.e.,
+   ``.eggs``, as well as the ``*.egg-info`` folders in the ``src`` folder or
+   potentially in the root of your project.
+
+#. Sometimes |tox|_ misses out when new dependencies are added, especially to
+   ``setup.cfg`` and ``docs/requirements.txt``. If you find any problems with
+   missing dependencies when running a command with |tox|_, try to recreate the
+   ``tox`` environment using the ``-r`` flag. For example, instead of::
+
+    tox -e docs
+
+   Try running::
+
+    tox -r -e docs
+
+#. Make sure to have a reliable |tox|_ installation that uses the correct
+   Python version (e.g., 3.7+). When in doubt you can run::
+
+    tox --version
+    # OR
+    which tox
+
+   If you have trouble and are seeing weird errors upon running |tox|_, you can
+   also try to create a dedicated `virtual environment`_ with a |tox|_ binary
+   freshly installed. For example::
+
+    virtualenv .venv
+    source .venv/bin/activate
+    .venv/bin/pip install tox
+    .venv/bin/tox -e all
+
+#. `Pytest can drop you`_ in an interactive session in the case an error occurs.
+   In order to do that you need to pass a ``--pdb`` option (for example by
+   running ``tox -- -k <NAME OF THE FALLING TEST> --pdb``).
+   You can also setup breakpoints manually instead of using the ``--pdb`` option.
+
+
+Maintainer tasks
+================
+
+Releases
+--------
+
+.. todo:: This section assumes you are using PyPI to publicly release your package.
+
+   If instead you are using a different/private package index, please update
+   the instructions accordingly.
+
+If you are part of the group of maintainers and have correct user permissions
+on PyPI_, the following steps can be used to release a new version for
+``swe2hs``:
+
+#. Make sure all unit tests are successful.
+#. Tag the current commit on the main branch with a release tag, e.g., ``v1.2.3``.
+#. Push the new tag to the upstream repository_, e.g., ``git push upstream v1.2.3``
+#. Clean up the ``dist`` and ``build`` folders with ``tox -e clean``
+   (or ``rm -rf dist build``)
+   to avoid confusion with old builds and Sphinx docs.
+#. Run ``tox -e build`` and check that the files in ``dist`` have
+   the correct version (no ``.dirty`` or git_ hash) according to the git_ tag.
+   Also check the sizes of the distributions, if they are too big (e.g., >
+   500KB), unwanted clutter may have been accidentally included.
+#. Run ``tox -e publish -- --repository pypi`` and check that everything was
+   uploaded to PyPI_ correctly.
+
+
+
+.. [#contrib1] Even though, these resources focus on open source projects and
+   communities, the general ideas behind collaborating with other developers
+   to collectively create software are general and can be applied to all sorts
+   of environments, including private companies and proprietary code bases.
+
+
+.. <-- strart -->
+.. todo:: Please review and change the following definitions:
+
+.. |the repository service| replace:: GitHub
+.. |contribute button| replace:: "Create pull request"
+
+.. _repository: https://github.com/<USERNAME>/swe2hs
+.. _issue tracker: https://github.com/<USERNAME>/swe2hs/issues
+.. <-- end -->
+
+
+.. |virtualenv| replace:: ``virtualenv``
+.. |pre-commit| replace:: ``pre-commit``
+.. |tox| replace:: ``tox``
+
+
+.. _black: https://pypi.org/project/black/
+.. _CommonMark: https://commonmark.org/
+.. _contribution-guide.org: https://www.contribution-guide.org/
+.. _creating a PR: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
+.. _descriptive commit message: https://chris.beams.io/posts/git-commit
+.. _docstrings: https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html
+.. _first-contributions tutorial: https://github.com/firstcontributions/first-contributions
+.. _flake8: https://flake8.pycqa.org/en/stable/
+.. _git: https://git-scm.com
+.. _GitHub's fork and pull request workflow: https://guides.github.com/activities/forking/
+.. _guide created by FreeCodeCamp: https://github.com/FreeCodeCamp/how-to-contribute-to-open-source
+.. _Miniconda: https://docs.conda.io/en/latest/miniconda.html
+.. _MyST: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html
+.. _other kinds of contributions: https://opensource.guide/how-to-contribute
+.. _pre-commit: https://pre-commit.com/
+.. _PyPI: https://pypi.org/
+.. _PyScaffold's contributor's guide: https://pyscaffold.org/en/stable/contributing.html
+.. _Pytest can drop you: https://docs.pytest.org/en/stable/usage.html#dropping-to-pdb-python-debugger-at-the-start-of-a-test
+.. _Python Software Foundation's Code of Conduct: https://www.python.org/psf/conduct/
+.. _reStructuredText: https://www.sphinx-doc.org/en/master/usage/restructuredtext/
+.. _Sphinx: https://www.sphinx-doc.org/en/master/
+.. _tox: https://tox.wiki/en/stable/
+.. _virtual environment: https://realpython.com/python-virtual-environments-a-primer/
+.. _virtualenv: https://virtualenv.pypa.io/en/stable/
+
+.. _GitHub web interface: https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files
+.. _GitHub's code editor: https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files

README.rst

+.. These are examples of badges you might want to add to your README:
+   please update the URLs accordingly
+
+    .. image:: https://api.cirrus-ci.com/github/<USER>/swe2hs.svg?branch=main
+        :alt: Built Status
+        :target: https://cirrus-ci.com/github/<USER>/swe2hs
+    .. image:: https://readthedocs.org/projects/swe2hs/badge/?version=latest
+        :alt: ReadTheDocs
+        :target: https://swe2hs.readthedocs.io/en/stable/
+    .. image:: https://img.shields.io/coveralls/github/<USER>/swe2hs/main.svg
+        :alt: Coveralls
+        :target: https://coveralls.io/r/<USER>/swe2hs
+    .. image:: https://img.shields.io/pypi/v/swe2hs.svg
+        :alt: PyPI-Server
+        :target: https://pypi.org/project/swe2hs/
+    .. image:: https://img.shields.io/conda/vn/conda-forge/swe2hs.svg
+        :alt: Conda-Forge
+        :target: https://anaconda.org/conda-forge/swe2hs
+    .. image:: https://pepy.tech/badge/swe2hs/month
+        :alt: Monthly Downloads
+        :target: https://pepy.tech/project/swe2hs
+    .. image:: https://img.shields.io/twitter/url/http/shields.io.svg?style=social&label=Twitter
+        :alt: Twitter
+        :target: https://twitter.com/swe2hs
+
+.. image:: https://img.shields.io/badge/-PyScaffold-005CA0?logo=pyscaffold
+    :alt: Project generated with PyScaffold
+    :target: https://pyscaffold.org/
+
+|
+
+======
+swe2hs
+======
+
+
+    Conceptual snow density model for transferring snow water equivalent to snow depth.
+
+
+A longer description of your project goes here...
+
+
+.. _pyscaffold-notes:
+
+Note
+====
+
+This project has been set up using PyScaffold 4.1.4. For details and usage
+information on PyScaffold see https://pyscaffold.org/.

docs/Makefile

+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?=
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = .
+BUILDDIR      = _build
+AUTODOCDIR    = api
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $?), 1)
+$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from https://sphinx-doc.org/")
+endif
+
+.PHONY: help clean Makefile
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+clean:
+	rm -rf $(BUILDDIR)/* $(AUTODOCDIR)
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

docs/_static/.gitignore

+# Empty directory

docs/authors.rst

+.. _authors:
+.. include:: ../AUTHORS.rst

docs/changelog.rst

+.. _changes:
+.. include:: ../CHANGELOG.rst

docs/conf.py

+# This file is execfile()d with the current directory set to its containing dir.
+#
+# This file only contains a selection of the most common options. For a full
+# list see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import os
+import sys
+import shutil
+
+# -- Path setup --------------------------------------------------------------
+
+__location__ = os.path.dirname(__file__)
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.join(__location__, "../src"))
+
+# -- Run sphinx-apidoc -------------------------------------------------------
+# This hack is necessary since RTD does not issue `sphinx-apidoc` before running
+# `sphinx-build -b html . _build/html`. See Issue:
+# https://github.com/readthedocs/readthedocs.org/issues/1139
+# DON'T FORGET: Check the box "Install your project inside a virtualenv using
+# setup.py install" in the RTD Advanced Settings.
+# Additionally it helps us to avoid running apidoc manually
+
+try:  # for Sphinx >= 1.7
+    from sphinx.ext import apidoc
+except ImportError:
+    from sphinx import apidoc
+
+output_dir = os.path.join(__location__, "api")
+module_dir = os.path.join(__location__, "../src/swe2hs")
+try:
+    shutil.rmtree(output_dir)
+except FileNotFoundError:
+    pass
+
+try:
+    import sphinx
+
+    cmd_line = f"sphinx-apidoc --implicit-namespaces -f -o {output_dir} {module_dir}"
+
+    args = cmd_line.split(" ")
+    if tuple(sphinx.__version__.split(".")) >= ("1", "7"):
+        # This is a rudimentary parse_version to avoid external dependencies
+        args = args[1:]
+
+    apidoc.main(args)
+except Exception as e:
+    print("Running `sphinx-apidoc` failed!\n{}".format(e))
+
+# -- General configuration ---------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+# needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = [
+    "sphinx.ext.autodoc",
+    "sphinx.ext.intersphinx",
+    "sphinx.ext.todo",
+    "sphinx.ext.autosummary",
+    "sphinx.ext.viewcode",
+    "sphinx.ext.coverage",
+    "sphinx.ext.doctest",
+    "sphinx.ext.ifconfig",
+    "sphinx.ext.mathjax",
+    "sphinx.ext.napoleon",
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ["_templates"]
+
+# The suffix of source filenames.