Plex plugin to to play various online streams (mostly Latvian).

index.txt 5.7KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189
  1. ====================================
  2. Mock - Mocking and Testing Library
  3. ====================================
  4. :Version: |release|
  5. :Date: |today|
  6. :Homepage: `Mock Homepage`_
  7. :Download: `Mock on PyPI`_
  8. :Documentation: `Python Docs`_
  9. :License: `BSD License`_
  10. :Support: `Mailing list (testing-in-python@lists.idyll.org)
  11. <http://lists.idyll.org/listinfo/testing-in-python>`_
  12. :Issue tracker: `Github Issues
  13. <https://github.com/testing-cabal/mock/issues>`_
  14. :Last sync: cb6aab1248c4aec4dd578bea717854505a6fb55d
  15. .. _Mock Homepage: https://github.com/testing-cabal/mock
  16. .. _BSD License: http://github.com/testing-cabal/mock/blob/master/LICENSE.txt
  17. .. _Python Docs: https://docs.python.org/dev/library/unittest.mock.html
  18. .. module:: mock
  19. :synopsis: Mock object and testing library.
  20. .. index:: introduction
  21. TOC
  22. +++
  23. .. toctree::
  24. :maxdepth: 2
  25. changelog
  26. Introduction
  27. ++++++++++++
  28. mock is a library for testing in Python. It allows you to replace parts of
  29. your system under test with mock objects and make assertions about how they
  30. have been used.
  31. mock is now part of the Python standard library, available as
  32. ``unittest.mock`` in Python 3.3 onwards. However, if you are writing code that
  33. runs on multiple versions of Python the ``mock`` package is better, as you get
  34. the newest features from the latest release of Python available for all
  35. Pythons.
  36. The ``mock`` package contains a rolling backport of the standard library mock
  37. code compatible with Python 2.6 and up, and 3.3 and up. Python 3.2 is supported
  38. by mock 1.3.0 and below - with pip no longer supporting 3.2, we cannot test
  39. against that version anymore.
  40. Please see the standard library documentation for usage details.
  41. .. index:: installing
  42. .. _installing:
  43. Installing
  44. ++++++++++
  45. The current version is |release|. Mock is stable and widely used.
  46. * `mock on PyPI <http://pypi.python.org/pypi/mock>`_
  47. .. index:: repository
  48. .. index:: git
  49. You can checkout the latest development version from Github
  50. repository with the following command:
  51. ``git clone https://github.com/testing-cabal/mock``
  52. .. index:: pip
  53. You can install mock with pip:
  54. | ``pip install -U mock``
  55. Alternatively you can download the mock distribution from PyPI and after
  56. unpacking run:
  57. ``python setup.py install``
  58. .. index:: bug reports
  59. Bug Reports
  60. +++++++++++
  61. Mock uses `unittest2 <http://pypi.python.org/pypi/unittest2>`_ for its own
  62. Issues with the backport process, such as compatibility with a particular
  63. Python, should be reported to the `bug tracker
  64. <https://github.com/testing-cabal/mock/issues>`_. Feature requests and issues
  65. with Mock functionality should be reported to the `Python bug tracker
  66. <https://bugs.python.org>`_.
  67. .. index:: python changes
  68. Python Changes
  69. ++++++++++++++
  70. Python NEWS entries from cPython:
  71. .. include:: ../NEWS
  72. .. index:: older versions
  73. Older Versions of Python
  74. ++++++++++++++++++++++++
  75. Version 1.0.1 is the last version compatible with Python < 2.6.
  76. .. index:: maintainer notes
  77. Maintainer Notes
  78. ++++++++++++++++
  79. Development
  80. ===========
  81. Checkout from git (see :ref:`installing`) and submit pull requests.
  82. Committers can just push as desired: since all semantic development takes
  83. place in cPython, the backport process is as lightweight as we can make it.
  84. mock is CI tested using Travis-CI on Python versions 2.6, 2.7, 3.3, 3.4,
  85. 3.5, nightly Python 3 builds, pypy, pypy3. Jython support is desired, if
  86. someone could contribute a patch to .travis.yml to support it that would be
  87. excellent.
  88. Releasing
  89. =========
  90. NB: please use semver. Bump the major component on API breaks, minor on all
  91. non-bugfix changes, patch on bugfix only changes.
  92. 1. tag -s, push --tags origin master
  93. 2. setup.py sdist bdist_wheel upload -s
  94. Backporting rules
  95. =================
  96. isinstance checks in cPython to ``type`` need to check ``ClassTypes``.
  97. Code calling ``obj.isidentifier`` needs to change to ``_isidentifier(obj)``.
  98. Backporting process
  99. ===================
  100. 1. Patch your git am with `my patch <https://github.com/rbtcollins/git>`_.
  101. 2. Install the applypatch-transform hook from tools/ to your .git hooks dir.
  102. 3. Configure a pre-applypatch hook to test at least all the cPython versions
  103. we support on each patch that is applied. I use containers, and a sample
  104. script is in tools/pre-applypatch.
  105. 4. Pull down the cPython git mirror: https://github.com/python/cpython.git
  106. 5. Export the new revisions since the ``Last sync`` at the top of this
  107. document::
  108. revs=${lastsync}
  109. rm migrate-export
  110. git log --pretty="format:%H " $revs.. -- Lib/unittest/mock.py \
  111. Lib/unittest/test/testmock/ > migrate-revs
  112. tac migrate-revs > migrate-sorted-revs
  113. for rev in $(< migrate-sorted-revs); do
  114. git format-patch -1 $rev -k --stdout >> migrate-export;
  115. done
  116. echo NEW SYNC POINT: $(git rev-parse HEAD)
  117. 6. Import into mock::
  118. git am -k --reject $path-to-cpython/migrate-export
  119. This will transform the patches automatically. Currently it will error
  120. on every NEWS change as I haven't gotten around to making those patches
  121. automatic. Fixup any errors that occur. When the patch is ready, do a ``git
  122. add -u`` to update the index and then ``git am --continue`` to move onto
  123. the next patch. If the patch is inappropriate e.g. the patch removing
  124. __ne__ which would break older pythons, then either do ``git reset --hard;
  125. git am --skip`` to discard any partially applied changes and skip over it,
  126. or, if it has a NEWS entry thats worth preserving, edit it down to just
  127. that, with a note such as we have for the ``__ne__`` patch, and continue on
  128. from there.
  129. The goal is that every patch work at all times.
  130. 7. After the import is complete, update this document with the new sync point.
  131. 8. Push to a personal branch and propose a PR to the main repo. This will make
  132. Travis-CI test it. If it works, push to the main repo.