From bbd34780b15b79056e6307ad71e5af016b47f5d4 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 9 Apr 2022 02:42:38 -0500 Subject: [PATCH 01/14] docs: Update release produre notes in dev docs --- docs/development.rst | 82 +++++++++++++++++++++++++++++++++----------- 1 file changed, 62 insertions(+), 20 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 798da6fcca..895360080a 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -59,7 +59,7 @@ TestPyPI ~~~~~~~~ ``pyhf`` tests packaging and distributing by publishing in advance of releases -to `TestPyPI `__. +to TestPyPI_. Installation of the latest test release from TestPyPI can be tested by first installing ``pyhf`` normally, to ensure all dependencies are installed from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI @@ -82,18 +82,65 @@ from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI Publishing ---------- -Publishing to `PyPI `__ and `TestPyPI `__ -is automated through the `PyPA's PyPI publish GitHub Action `__ -and the ``pyhf`` `Tag Creator GitHub Actions workflow `__. -A release can be created from any PR created by a core developer by adding a -``bumpversion`` tag to it that corresponds to the release type: -`major `__, -`minor `__, -`patch `__. -Once the PR is tagged with the label, the GitHub Actions bot will post a comment -with information on the actions it will take once the PR is merged. When the PR -has been reviewed, approved, and merged, the Tag Creator workflow will automatically -create a new release with ``bump2version`` and then deploy the release to PyPI. +Publishing to PyPI_ and TestPyPI_ is automated through the `PyPA's PyPI publish +GitHub Action `__ +and the ``pyhf`` `Bump version GitHub Actions workflow +`__. + + +Release Checklist +~~~~~~~~~~~~~~~~~ + +As part of the release process a checklist is required to be completed to make +sure steps aren't missed. +There is a GitHub Issue template for this that the maintainer in charge of the +release should step through and update if needed. + +Release Tags +~~~~~~~~~~~~ + +A release tag can be created by a maintainer by using the bump version workflow +through GitHub Actions workflow dispatch. +The maintainer needs to: + +* Select the semantic versioning (SemVer) type (major, minor, patch) of the release tag. +* Select if the release tag is a release candidate or not. +* Input the SemVer version number of the release tag. +* Select if to override the SemVer compatibility of the previous options (default + is to run checks). +* Select if a dry run should be performed (default is to do a dry run to avoid accidental + release tags). + +The maintainer should do a dry run first to make sure everything looks reasonable. +Once they have done that, they can run the bump version workflow which will produce +a new tag, bump the version of all files defined in `tbump.toml +`__, and then commit and +push these changes and the tag back to the ``master`` branch. + +Deployment +~~~~~~~~~~ + +The push of a tag to the repository will trigger a build of a sdist and wheel, and then +the deployment of them to TestPyPI_. +Once the deployment has been examined, installed, and tested locally by the maintainers +final deployment to PyPI_ can be done. + +Releases are performed through GitHub Releases. + +* From the ``pyhf`` `GitHub releases page `__ + select the `"Draft a new release" `__ + button. +* Select the release tag that was just pushed, and set the release title to be the tag + (e.g. `v1.2.3`). +* Use the "Auto-generate release notes" button to generate a skeleton of the release + notes and then augment them with the preprepared release notes the release maintainer + has written. +* Select "This is a pre-release" if the release is a release candidate. +* Select "Create a discussion for this release" if the release is a stable release. +* Select "Publish release". + +Once the release has been published to GitHub, the publishing workflow will build a +sdist and wheel, and then deploy them to PyPI_. Context Files and Archive Metadata ---------------------------------- @@ -112,10 +159,5 @@ though the ``author`` metadata will still need to be checked and revised by hand The ``.zenodo.json`` is currently generated by hand, so it is worth using ``codemeta.json`` as a guide to edit it. -Release Checklist ------------------ - -As part of the release process a checklist is required to be completed to make -sure steps aren't missed. -There is a GitHub Issue template for this that the developer in charge of the -release should step through and update if needed. +.. _PyPI: https://pypi.org/project/pyhf/ +.. _TestPyPI: https://test.pypi.org/project/pyhf/ From fd82647114d5c314afea11592bb44d5e878d4eb2 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 9 Apr 2022 03:17:41 -0500 Subject: [PATCH 02/14] Put TestPyPI first --- docs/development.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 895360080a..d53a163648 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -82,12 +82,11 @@ from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI Publishing ---------- -Publishing to PyPI_ and TestPyPI_ is automated through the `PyPA's PyPI publish +Publishing to TestPyPI_ and PyPI_ is automated through the `PyPA's PyPI publish GitHub Action `__ and the ``pyhf`` `Bump version GitHub Actions workflow `__. - Release Checklist ~~~~~~~~~~~~~~~~~ From dbe3368dc74341233a4cb8925f6a11aaa757eb6c Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 9 Apr 2022 12:32:31 -0500 Subject: [PATCH 03/14] Update pre-commit notes --- docs/development.rst | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index d53a163648..a98a0e55dd 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -17,20 +17,16 @@ and install all necessary packages for development python -m pip install --upgrade --editable .[complete] -Then setup the Git pre-commit hook for `Black `__ by running +Then setup the Git `pre-commit `__ hooks by running .. code-block:: console pre-commit install -as the ``rev`` gets updated through time to track changes of different hooks, -simply run - -.. code-block:: console - - pre-commit autoupdate - -to have pre-commit install the new version. +inside of the virtual environment. +`pre-commit.ci `__ keeps the pre-commit hooks updated +through time, so pre-commit will automatically update itself when you run it +locally after the hooks were updated. Testing ------- From e63db48ab4dd8856fec13b9decae84e0cd2bbb20 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Sat, 9 Apr 2022 12:34:36 -0500 Subject: [PATCH 04/14] Remove pipenv recommendation --- docs/development.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/development.rst b/docs/development.rst index a98a0e55dd..eb899cc5f8 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -5,7 +5,10 @@ Developing Developer Environment --------------------- -To develop, we suggest using `virtual environments `__ together with ``pip`` or using `pipenv `__. Once the environment is activated, clone the repo from GitHub +To develop, we suggest using `virtual environments +`__ +together with ``pip``. +Once the virtual environment is activated, clone the repo from GitHub .. code-block:: console From fe6995e70d10d0ef0a04709a42145aa41eb718c8 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 01:31:29 -0500 Subject: [PATCH 05/14] Update bump2version to tbump --- docs/development.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development.rst b/docs/development.rst index eb899cc5f8..2c4ce54b15 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -144,7 +144,7 @@ Context Files and Archive Metadata ---------------------------------- The ``.zenodo.json`` and ``codemeta.json`` files have the version number -automatically updated through ``bump2version``, though their additional metadata +automatically updated through ``tbump``, though their additional metadata should be checked periodically by the dev team (probably every release). The ``codemeta.json`` file can be generated automatically **from a PyPI install** of ``pyhf`` using ``codemetapy`` From af88750cecae2849cf6f82fffdf1b49ee2fb0787 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:01:47 -0500 Subject: [PATCH 06/14] Add pytest section --- docs/development.rst | 43 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 2c4ce54b15..0fd61f432b 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -5,14 +5,16 @@ Developing Developer Environment --------------------- -To develop, we suggest using `virtual environments +To develop, we suggest using Python `virtual environments `__ together with ``pip``. -Once the virtual environment is activated, clone the repo from GitHub +Once the virtual environment is activated and you have `SSH keys setup with GitHub +`__, clone the +repo from GitHub .. code-block:: console - git clone https://github.com/scikit-hep/pyhf.git + git clone git@github.com:scikit-hep/pyhf.git and install all necessary packages for development @@ -34,6 +36,41 @@ locally after the hooks were updated. Testing ------- +To run the test suite in full, from the top level of the repository run + +.. code-block:: console + + pytest + +more practically for most local testing you will not want to test the benchmarks, +contrib module, or notebooks, and so instead to test the core codebase can run + +.. code-block:: console + + pytest --ignore tests/benchmarks/ --ignore tests/contrib --ignore tests/test_notebooks.py + +Contrib module matplotlib image tests +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To run the visualization tests for the ``contrib`` module with the ``pytest-mpl`` +``pytest`` plugin run + +.. code-block:: console + + pytest tests/contrib --mpl --mpl-baseline-path tests/contrib/baseline --mpl-generate-summary html + +Doctest +~~~~~~~ + +``pyhf``'s configuration of ``pytest`` will automatically run ``doctest`` on all the +modules when the full test suite is run. +To run ``doctest`` on an individual module or file just run ``pytest`` on its path. +For example, to run ``doctest`` on the JAX backend run + +.. code-block:: console + + pytest src/pyhf/tensor/jax_backend.py + Data Files ~~~~~~~~~~ From 3c12d5578a57cb5435e4b85898b323ba9aa1462a Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:02:07 -0500 Subject: [PATCH 07/14] Add TestPyPI to distribution part --- docs/development.rst | 53 ++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 0fd61f432b..6396648b00 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -91,30 +91,6 @@ which will load the copy of ``text.txt`` in the temporary directory. This also works for parameterizations as this will effectively sandbox the file modifications made. -TestPyPI -~~~~~~~~ - -``pyhf`` tests packaging and distributing by publishing in advance of releases -to TestPyPI_. -Installation of the latest test release from TestPyPI can be tested -by first installing ``pyhf`` normally, to ensure all dependencies are installed -from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI - -.. code-block:: bash - - python -m pip install pyhf - python -m pip install --upgrade --extra-index-url https://test.pypi.org/simple/ --pre pyhf - -.. note:: - - This adds TestPyPI as `an additional package index to search `__ - when installing. - PyPI will still be the default package index ``pip`` will attempt to install - from for all dependencies, but if a package has a release on TestPyPI that - is a more recent release then the package will be installed from TestPyPI instead. - Note that dev releases are considered pre-releases, so ``0.1.2`` is a "newer" - release than ``0.1.2.dev3``. - Publishing ---------- @@ -157,6 +133,35 @@ Deployment The push of a tag to the repository will trigger a build of a sdist and wheel, and then the deployment of them to TestPyPI_. + +TestPyPI +^^^^^^^^ + +``pyhf`` tests packaging and distributing by publishing in advance of releases +to TestPyPI_. +Installation of the latest test release from TestPyPI can be tested +by first installing ``pyhf`` normally, to ensure all dependencies are installed +from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI + +.. code-block:: bash + + python -m pip install pyhf + python -m pip install --upgrade --extra-index-url https://test.pypi.org/simple/ --pre pyhf + +.. note:: + + This adds TestPyPI as `an additional package index to search + `__ + when installing. + PyPI will still be the default package index ``pip`` will attempt to install + from for all dependencies, but if a package has a release on TestPyPI that + is a more recent release then the package will be installed from TestPyPI instead. + Note that dev releases are considered pre-releases, so ``0.1.2`` is a "newer" + release than ``0.1.2.dev3``. + +PyPI +^^^^ + Once the deployment has been examined, installed, and tested locally by the maintainers final deployment to PyPI_ can be done. From 10d5218e76efbd642f1e18a909b9e46cb0036466 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:15:23 -0500 Subject: [PATCH 08/14] Update testing sections --- docs/development.rst | 50 +++++++++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index 6396648b00..e684f21657 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -36,6 +36,32 @@ locally after the hooks were updated. Testing ------- +Writing tests +~~~~~~~~~~~~~ + +Data Files +^^^^^^^^^^ + +A function-scoped fixture called ``datadir`` exists for a given test module +which will automatically copy files from the associated test modules data +directory into a temporary directory for the given test execution. That is, for +example, if a test was defined in ``test_schema.py``, then data files located +in ``test_schema/`` will be copied to a temporary directory whose path is made +available by the ``datadir`` fixture. Therefore, one can do: + +.. code-block:: python + + def test_patchset(datadir): + data_file = open(datadir.join("test.txt")) + ... + +which will load the copy of ``text.txt`` in the temporary directory. This also +works for parameterizations as this will effectively sandbox the file +modifications made. + +Running with pytest +~~~~~~~~~~~~~~~~~~~ + To run the test suite in full, from the top level of the repository run .. code-block:: console @@ -50,7 +76,7 @@ contrib module, or notebooks, and so instead to test the core codebase can run pytest --ignore tests/benchmarks/ --ignore tests/contrib --ignore tests/test_notebooks.py Contrib module matplotlib image tests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To run the visualization tests for the ``contrib`` module with the ``pytest-mpl`` ``pytest`` plugin run @@ -60,7 +86,7 @@ To run the visualization tests for the ``contrib`` module with the ``pytest-mpl` pytest tests/contrib --mpl --mpl-baseline-path tests/contrib/baseline --mpl-generate-summary html Doctest -~~~~~~~ +^^^^^^^ ``pyhf``'s configuration of ``pytest`` will automatically run ``doctest`` on all the modules when the full test suite is run. @@ -71,26 +97,6 @@ For example, to run ``doctest`` on the JAX backend run pytest src/pyhf/tensor/jax_backend.py -Data Files -~~~~~~~~~~ - -A function-scoped fixture called ``datadir`` exists for a given test module -which will automatically copy files from the associated test modules data -directory into a temporary directory for the given test execution. That is, for -example, if a test was defined in ``test_schema.py``, then data files located -in ``test_schema/`` will be copied to a temporary directory whose path is made -available by the ``datadir`` fixture. Therefore, one can do: - -.. code-block:: python - - def test_patchset(datadir): - data_file = open(datadir.join("test.txt")) - ... - -which will load the copy of ``text.txt`` in the temporary directory. This also -works for parameterizations as this will effectively sandbox the file -modifications made. - Publishing ---------- From b132b3c75b029b40119fd9662c8bb92db1880027 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:15:51 -0500 Subject: [PATCH 09/14] Make enumerated list --- docs/development.rst | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index e684f21657..e779fb2ea1 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -129,7 +129,8 @@ The maintainer needs to: release tags). The maintainer should do a dry run first to make sure everything looks reasonable. -Once they have done that, they can run the bump version workflow which will produce +Once they have done that, they can run the `bump version GitHub Actions workflow +`__ which will produce a new tag, bump the version of all files defined in `tbump.toml `__, and then commit and push these changes and the tag back to the ``master`` branch. @@ -168,22 +169,20 @@ from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI PyPI ^^^^ -Once the deployment has been examined, installed, and tested locally by the maintainers -final deployment to PyPI_ can be done. - -Releases are performed through GitHub Releases. - -* From the ``pyhf`` `GitHub releases page `__ - select the `"Draft a new release" `__ - button. -* Select the release tag that was just pushed, and set the release title to be the tag - (e.g. `v1.2.3`). -* Use the "Auto-generate release notes" button to generate a skeleton of the release - notes and then augment them with the preprepared release notes the release maintainer - has written. -* Select "This is a pre-release" if the release is a release candidate. -* Select "Create a discussion for this release" if the release is a stable release. -* Select "Publish release". +Once the TestPyPI deployment has been examined, installed, and tested locally by the maintainers +final deployment to PyPI_ can be done by creating a GitHub Release: + +#. From the ``pyhf`` `GitHub releases page `__ + select the `"Draft a new release" `__ + button. +#. Select the release tag that was just pushed, and set the release title to be the tag + (e.g. `v1.2.3`). +#. Use the "Auto-generate release notes" button to generate a skeleton of the release + notes and then augment them with the preprepared release notes the release maintainer + has written. +#. Select "This is a pre-release" if the release is a release candidate. +#. Select "Create a discussion for this release" if the release is a stable release. +#. Select "Publish release". Once the release has been published to GitHub, the publishing workflow will build a sdist and wheel, and then deploy them to PyPI_. From 175831c04d9d3a77d1bc01c562caf5354343b03f Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:19:53 -0500 Subject: [PATCH 10/14] Revise for clarity --- docs/development.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index e779fb2ea1..c51ff447a9 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -68,8 +68,8 @@ To run the test suite in full, from the top level of the repository run pytest -more practically for most local testing you will not want to test the benchmarks, -contrib module, or notebooks, and so instead to test the core codebase can run +More practically for most local testing you will not want to test the benchmarks, +contrib module, or notebooks, and so instead to test the core codebase a developer can run .. code-block:: console @@ -144,13 +144,13 @@ the deployment of them to TestPyPI_. TestPyPI ^^^^^^^^ -``pyhf`` tests packaging and distributing by publishing in advance of releases -to TestPyPI_. +``pyhf`` tests packaging and distribution by publishing to TestPyPI_ in advance of +releases. Installation of the latest test release from TestPyPI can be tested by first installing ``pyhf`` normally, to ensure all dependencies are installed from PyPI, and then upgrading ``pyhf`` to a test release from TestPyPI -.. code-block:: bash +.. code-block:: console python -m pip install pyhf python -m pip install --upgrade --extra-index-url https://test.pypi.org/simple/ --pre pyhf @@ -196,7 +196,7 @@ should be checked periodically by the dev team (probably every release). The ``codemeta.json`` file can be generated automatically **from a PyPI install** of ``pyhf`` using ``codemetapy`` -.. code-block:: bash +.. code-block:: console codemetapy --no-extras pyhf > codemeta.json From d1bb9d20ba075399a1cdfae5f875d53d2ed6b166 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:22:34 -0500 Subject: [PATCH 11/14] case --- docs/development.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development.rst b/docs/development.rst index c51ff447a9..c8459d602f 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -102,7 +102,7 @@ Publishing Publishing to TestPyPI_ and PyPI_ is automated through the `PyPA's PyPI publish GitHub Action `__ -and the ``pyhf`` `Bump version GitHub Actions workflow +and the ``pyhf`` `bump version GitHub Actions workflow `__. Release Checklist From 83caeb9ecdab66476f0374747b7af024d13ca8d6 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:35:24 -0500 Subject: [PATCH 12/14] Improve links --- docs/development.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/development.rst b/docs/development.rst index c8459d602f..b44d8d0126 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -116,8 +116,8 @@ release should step through and update if needed. Release Tags ~~~~~~~~~~~~ -A release tag can be created by a maintainer by using the bump version workflow -through GitHub Actions workflow dispatch. +A release tag can be created by a maintainer by using the `bump version GitHub Actions +workflow`_ through workflow dispatch. The maintainer needs to: * Select the semantic versioning (SemVer) type (major, minor, patch) of the release tag. @@ -128,10 +128,9 @@ The maintainer needs to: * Select if a dry run should be performed (default is to do a dry run to avoid accidental release tags). -The maintainer should do a dry run first to make sure everything looks reasonable. -Once they have done that, they can run the `bump version GitHub Actions workflow -`__ which will produce -a new tag, bump the version of all files defined in `tbump.toml +The maintainer **should do a dry run first to make sure everything looks reasonable**. +Once they have done that, they can run the `bump version GitHub Actions workflow`_ which +will produce a new tag, bump the version of all files defined in `tbump.toml `__, and then commit and push these changes and the tag back to the ``master`` branch. @@ -204,5 +203,6 @@ though the ``author`` metadata will still need to be checked and revised by hand The ``.zenodo.json`` is currently generated by hand, so it is worth using ``codemeta.json`` as a guide to edit it. +.. _bump version GitHub Actions workflow: https://github.com/scikit-hep/pyhf/actions/workflows/bump-version.yml .. _PyPI: https://pypi.org/project/pyhf/ .. _TestPyPI: https://test.pypi.org/project/pyhf/ From 5106a06ea2d925e62969f8fc0d7069ea4b8d2c20 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 13 Apr 2022 12:48:59 -0500 Subject: [PATCH 13/14] formatting fix --- docs/development.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development.rst b/docs/development.rst index b44d8d0126..4a45b763cf 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -175,7 +175,7 @@ final deployment to PyPI_ can be done by creating a GitHub Release: select the `"Draft a new release" `__ button. #. Select the release tag that was just pushed, and set the release title to be the tag - (e.g. `v1.2.3`). + (e.g. ``v1.2.3``). #. Use the "Auto-generate release notes" button to generate a skeleton of the release notes and then augment them with the preprepared release notes the release maintainer has written. From c8e8a5d244e36dca1f2b489a95df920749cd7f25 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Fri, 15 Apr 2022 12:28:09 -0500 Subject: [PATCH 14/14] Drop the .git as not needed since Git v2.0 released in 2014 --- docs/development.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development.rst b/docs/development.rst index 4a45b763cf..c146f26908 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -14,7 +14,7 @@ repo from GitHub .. code-block:: console - git clone git@github.com:scikit-hep/pyhf.git + git clone git@github.com:scikit-hep/pyhf and install all necessary packages for development