diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b5cad3bcd9f9fbe7447333a486fc059c764f34ad..7f06615b5cea7b69218515d600424d1990f5ce83 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,224 +1,257 @@
-
-Contributing to bilby
-=================
-
-This is a short guide to help get you started contributing to bilby.
-
-Getting started
--------------------
-
-All the code lives in a git repository (for a short introduction to git, see
-[this tutorial](https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html))
-which is hosted here: https://git.ligo.org/lscsoft/bilby. If you haven't
-already, you should
-[fork](https://docs.gitlab.com/ee/gitlab-basics/fork-project.html) the repository
-and clone your fork, i.e., on your local machine run
-
-```bash
-$ git clone git@git.ligo.org:albert.einstein/bilby.git
+# Contributing to bilby
+
+This is a short guide to contributing to bilby aimed at general LVC members who
+have some familiarity with python and git.
+
+1. [Code of conduct](#code-of-conduct)
+2. [Code style](#code-style)
+3. [Code relevance](#code-relevance)
+4. [Merge requests](#merge-requests)
+5. [Typical workflow](#typical-workflow)
+6. [Hints and tips](#hints-and-tips)
+7. [Code overview](#code-overview)
+
+
+## Code of Conduct
+
+Everyone participating in the bilby community, and in particular in our issue
+tracker, merge requests, and chat channels, is expected to treat other people
+with respect and follow the guidelines articulated in the [Python Community
+Code of Conduct](https://www.python.org/psf/codeofconduct/).
+
+## Code style
+
+During a code review (when you want to contribute changes to the code base),
+you may be asked to change your code to fit with the bilby style. This is based
+on a few python conventions and is generally maintained to ensure the code base
+remains consistent and readable to new users. Here we list some typical things
+to keep in mind ensuring the code review is as smooth as possible
+
+1. We follow the [standard python PEP8](https://www.python.org/dev/peps/pep-0008/) conventions for style. While the testing of this is largely automated (the C.I. pipeline tests check using [flake8](http://flake8.pycqa.org/en/latest/)), some more subjective things might slip the net.
+2. New classes/functions/methods should have a docstring and following the [numpy docstring guide](https://numpydoc.readthedocs.io/en/latest/format.html), for example
+```python
+def my_new_function(x, y, print=False):
+ """ A function to calculate the sum of two numbers
+
+ Parameters
+ ----------
+ x, y: float
+ Input numbers to sum
+ print: bool
+ If true, print a message
+ """
+ if print:
+ print("Message!")
+ return x + y
```
+3. Avoid inline comments unless necessary. Ideally, the code should make it obvious what is going on, if not the docstring, only in subtle cases use comments
+4. Name variables sensibly. Avoid using single-letter variables, it is better to name something `power_spectral_density_array` than `psda`.
+5. Don't repeat yourself. If code is repeated in multiple places, wrap it up into a function.
+6. Add tests. The C.I. is there to do the work of "checking" the code, both now and into the future. Use it.
-replacing the SSH url to that of your fork. This will create a directory `/bilby`
-containing a local copy of the code. From this directory, you can run
-
-```bash
-$ python setup.py develop
-```
+## Code relevance
-which will install `bilby` and, because we used `develop` instead of `install`
-when you change the code your installed version will automatically be updated.
+The bilby code base is intended to be highly modular and flexible. We encourage
+people to "develop into" the code base new features and tools that will be
+widely used. On the other hand, if you are developing a tool which might be
+highly specialised, it might make more sense to develop a separate python
+module which **depends** on bilby, but doesn't need to live in the bilby source
+code. Adding code into the bilby source comes with advantages, but also adds
+complexity and review burden to the project. If you are unsure where it should
+live, open an issue to discuss it.
----
+## Merge requests
-#### Removing previously installed versions
-
-If you have previously installed `bilby` using `pip` (or generally find buggy
-behaviour), it may be worthwhile purging your system and reinstalling. To do
-this, first find out where the module is being imported from: from any
-directory that is *not* the source directory, do the following
+All changes to the code base go through the [merge-request
+workflow](https://docs.gitlab.com/ee/user/project/merge_requests/) Anyone may
+review your code and you should expect a few comments and questions. Once all
+discussions are resolved, core developers will approve the merge request and
+then merge it into the master branch. If you go a few days without a reply,
+please feel free to ping the thread by adding a new comment.
-```bash
-$ python
->>> import bilby
->>> print(bilby.__file__)
-/home/user/anaconda2/lib/python2.7/site-packages/bilby-0.2.2-py2.7.egg/bilby/__init__.pyc
-```
-In the example output above, we see that the directory that module is installed
-in. To purge our python installation, run
+All merge requests should be focused: they should aim to either add one
+feature, solve one bug, or fix some stylistic issues. If multiple changes are
+lumped together it can slow down the process and make it harder to review.
-```bash
-$ rm -r /home/user/anaconda2/lib/python2.7/site-packages/bilby*
-```
+Before you begin: we highly recommend starting by opening an issue laying out
+what you want to do, especially if your change will be a significant amount of
+work to write. This lets a conversation happen early in case other
+contributors disagree with what you'd like to do or have ideas that will help
+you do it.
-You can then verify this was successful by trying to import bilby in the python
-interpreter.
+Comments and questions may pertain to the functionality, but they may also
+relate to the code quality. We are keen to maintain a high standard of the
+code. This makes it easier to maintain, develop, and track down buggy
+behaviour. See the [Code style](#code-style) Section for an overview.
-Discussion
-----------
+**Reviewing Changes**
-If you've run into behavior you don't understand, or you're
-having trouble working out a good way to apply it to your code, or
-you've found a bug or would like a feature it doesn't have, we want to
-hear from you!
+If you are reviewing a merge request (either as a core developer or just as an
+interested party) please keep these three things in mind
-Our main forum for discussion is the project's [GitLab issue
-tracker](https://git.ligo.org/lscsoft/bilby/issues). This is the right
-place to start a discussion of any of the above or most any other
-topic concerning the project.
+* If you open a discussion, be timely in responding to the submitter. Note, the
+ reverse does not need to apply.
+* Keep your questions/comments focused on the scope of the merge request. If
+ while reviewing the code you notice other things which could be improved,
+ open a new issue.
+* Be supportive - merge requests represent a lot of hard work and effort and
+ should be encouraged.
-#### Code of Conduct
+Reviewers should follow these rules when processing merge requests:
-Everyone participating in the bilby community, and in particular in our
-issue tracker, merge requests, and IRC channel, is expected to treat
-other people with respect and more generally to follow the guidelines
-articulated in the [Python Community Code of
-Conduct](https://www.python.org/psf/codeofconduct/).
+* Always wait for tests to pass before merging MRs.
+* Delete branches for merged MRs (by core devs pushing to the main repo).
+* Make sure related issues are linked and (if appropriate) closed.
+* Squash commits
+## Typical workflow
-Submitting Changes
-------------------------
+Bilby uses the fork and merge model for code review and contributing to the
+repository. As such, you won't be able to push changes to the master branch.
+Instead, you'll need to create a fork, make your changes on a feature branch,
+then submit a merge request. The following subsections walk you through how to
+do this.
-All changes to the code base go through the [merge-request
-workflow](https://docs.gitlab.com/ee/user/project/merge_requests/) Anyone may
-review your code and you may expect a few comments and questions. Once all
-discussions are resolved, core developers will approve the merge request and
-then merge in into master. If you go a few days without a reply, please feel
-free to ping the thread by adding a new comment.
+### Step a) getting started
-All merge requests should be focused: they should aim to either add one
-feature, solve one bug, or fix some stylistic issues. If multiple changes are
-lumped together it can slow down the process and make it harder to review.
+All the code lives in a git repository (for a short introduction to git, see
+[this tutorial](https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html))
+which is hosted here: https://git.ligo.org/lscsoft/bilby. If you haven't
+already, you should
+[fork](https://docs.gitlab.com/ee/gitlab-basics/fork-project.html) the
+repository and clone your fork, i.e., on your local machine run
-Before you begin: if your change will be a significant amount of work
-to write, we highly recommend starting by opening an issue laying out
-what you want to do. That lets a conversation happen early in case
-other contributors disagree with what you'd like to do or have ideas
-that will help you do it.
+```bash
+$ git clone git@git.ligo.org:albert.einstein/bilby.git
+```
-We are keen to maintain a high standard of the code. This makes it easier to
-maintain, develop, and track down buggy behaviour.
+replacing the SSH url to that of your fork. This will create a directory
+`/bilby` containing a local copy of the code. From this directory, you can run
-All merge requests should also be recorded in the CHANGELOG.md.
-This just requires a short sentence describing describing the change, e.g.,
-"- Enable initial values for emcee to be specified."
+```bash
+$ pip install -e .
+```
-#### Updating your fork
+which will install `bilby` using the python package installer `pip`. The `-e`
+argument will mean that when you change the code your installed version will
+automatically be updated.
-If you already have a fork of bilby, and are starting work on a new project you can link your clone to the main (`lscsoft`) repository and pull in changes that have been merged since the time you created your fork, or last updated:
+### Step b) Updating your fork
-1. Link your fork to the main repository:
+If you already have a fork of bilby, and are starting work on a new project you
+can link your clone to the main (`lscsoft`) repository and pull in changes that
+have been merged since the time you created your fork, or last updated:
-From the directory `/bilby` containing a local copy of the code:
+**Link your fork to the main repository:** from the directory `/bilby`
+containing a local copy of the code:
```bash
$ git remote add lscsoft https://git.ligo.org/lscsoft/bilby
```
-2. Fetch new changes from the `lscsoft` repo
+You can see which "remotes" you have available by running
```bash
-$ git fetch lscsoft
+$ git remote -v
```
-### Creating a new feature branch
+**Fetch new changes from the `lscsoft` repo:**
-All changes should be developed on a feature branch, in order to keep them separate from other work, simplifying review and merge once the work is done.
+```bash
+$ git pull lscsoft master
+```
+
+### Step c) Creating a new feature branch
+All changes should be developed on a feature branch, in order to keep them
+separate from other work, simplifying review and merging once the work is done.
To create a new feature branch:
```bash
-$ git fetch lscsoft
+$ git pull lscsoft
$ git checkout -b my-new-feature lscsoft/master
```
-### Hack away
-
-1. Develop the changes you would like to introduce, using `git commit` to finalise a specific change.
- Ideally commit small units of change often, rather than creating one large commit at the end, this will simplify review and make modifying any changes easier.
+### Step d) Hack away
- Commit messages should be clear, identifying which code was changed, and why.
- Common practice is to use a short summary line (<50 characters), followed by a blank line, then more information in longer lines.
-
-2. Push your changes to the remote copy of your fork on git.ligo.org
+1. Develop the changes you would like to introduce, using `git add` to add files with changes. Ideally commit small units of change often, rather than creating one large commit at the end, this will simplify review and make modifying any changes easier.
+2. Commit the changes using `git commit`. This will prompt you for a commit message. Commit messages should be clear, identifying which code was changed, and why. Common practice (see e.g. [this blog](https://chris.beams.io/posts/git-commit/)) is to use a short summary line (<50 characters), followed by a blank line, then more information in longer lines.
+3. Push your changes to the remote copy of your fork on git.ligo.org
```bash
git push origin my-new-feature
```
-**Note:** For the first `push` of any new feature branch, you will likely have to use the `-u/--set-upstream` option to `push` to create a link between your new branch and the `origin` remote:
+**Note:** For the first `push` of any new feature branch, you will likely have
+to use the `-u/--set-upstream` option to `push` to create a link between your
+new branch and the `origin` remote:
```bash
git push --set-upstream origin my-new-feature
```
-### Open a Merge Request
-
-When you feel that your work is finished, or if you want feedback on it, you should create a Merge Request to propose that your changes be merged into the main (`lscsoft`) repository.
+### Step e) Open a Merge Request
-After you have pushed your new feature branch to `origin`, you should find a new button on the [bilby repository home page](https://git.ligo.org/lscsoft/bilby) inviting you to create a Merge Request out of your newly pushed branch.
-You should click the button, and proceed to fill in the title and description boxes on the MR page. If you are still working on the merge request and don’t want it to be merged accidentally, add the string "wip", "work in progress" or "do not merge" (not case-sensitive), to the title.
+When you feel that your work is finished, or if you want feedback on it, you
+should create a Merge Request to propose that your changes be merged into the
+main (`lscsoft`) repository.
-Once the request has been opened, one of the maintainers will assign someone to review the change.
+After you have pushed your new feature branch to `origin`, you should find a
+new button on the [bilby repository home
+page](https://git.ligo.org/lscsoft/bilby) inviting you to create a Merge
+Request out of your newly pushed branch. You should click the button, and
+proceed to fill in the title and description boxes on the MR page. If you are
+still working on the merge request and don’t want it to be merged accidentally,
+add the string "WIP", "work in progress" or "do not merge" (not
+case-sensitive), to the title.
+Once the request has been opened, one of the maintainers will assign someone to
+review the change.
-ADD DISCUSSION ON CODE QUALITY
+## Hints and tips
-Reviewing Changes
------------------
+### Licence
+When submitting a MR, please don't include any license information in your
+code. Our repository is
+[licensed](https://git.ligo.org/lscsoft/bilby/blob/master/LICENSE.md). When
+submitting your merge request, we will assume you have read and agreed to the
+terms of [the
+license](https://git.ligo.org/lscsoft/bilby/blob/master/LICENSE.md).
-If you are reviewing a merge request (either as a core developer or just as an
-interested party) please key these three things in mind
+### Removing previously installed versions
-* If you open a discussion, be timely in responding to the submitter. Note, the
- reverse does not need to apply.
-* Keep your questions/comments focused on the scope of the merge request. If
- while reviewing the code you notice other things which could be improved, open
- a new issue.
-* Be supportive - merge requests represent a lot of hard work and effort and
- should be encouraged.
-
-Core developer guidelines
--------------------------
-
-Core developers should follow these rules when processing merge requests:
-
-* Always wait for tests to pass before merging MRs.
-* Delete branches for merged MRs (by core devs pushing to the main repo).
-* Make sure related issues are linked and (if appropriate) closed.
-* Squash commits
-
-
-Issue-tracker conventions
--------------------------
-
-#### Bug reporting
-
-If you notice any bugs in the code, please let us know!
-
-Issues reporting bugs should include:
-* A brief description of the issue.
-* A full error trace (if applicable).
-* A minimal example to reproduce the issue.
-
-#### Feature requests
+If you have previously installed `bilby` using `pip` (or generally find buggy
+behaviour), it may be worthwhile purging your system and reinstalling. To do
+this, first find out where the module is being imported from: from any
+directory that is *not* the source directory, do the following
-If there's any additional functionality you'd like to see in the code open an
-issue describing the desired feature.
+```bash
+$ python
+>>> import bilby
+>>> print(bilby.__file__)
+/home/user/anaconda2/lib/python2.7/site-packages/bilby-0.2.2-py2.7.egg/bilby/__init__.pyc
+```
+In the example output above, we see that the directory that module is installed
+in. To purge our python installation, run
-In order to maximise the likelihood that feature requests will be fulfilled
-you should:
-* Make the feature request as specific as possible, vague requests are
- unlikely to be taken on by users.
-* If possible break down the feature into small chunks which can be
- marked off on a checklist.
+```bash
+$ rm -r /home/user/anaconda2/lib/python2.7/site-packages/bilby*
+```
+You can then verify this was successful by trying to import bilby in the python
+interpreter.
## Code overview
-In this section, we'll give an overview of how the code is structured. This is intended to help orient users and make it easier to contribute. The layout is intended to define the logic of the code and new merge requests should aim to fit within this logic (unless there is a good argument to change it). For example, code which adds a new sampler should not effect the gravitational-wave specific parts of the code. Note that this document is not programatically generated and so may get out of date with time. If you notice something wrong, please open an issue.
-
-### Bilby Code Layout
+Below, we give a schematic of how the code is structured. This is intended to
+help orient users and make it easier to contribute. The layout is intended to
+define the logic of the code and new merge requests should aim to fit within
+this logic (unless there is a good argument to change it). For example, code
+which adds a new sampler should not effect the gravitational-wave specific
+parts of the code. Note that this document is not programatically generated and
+so may get out of date with time. If you notice something wrong, please open an
+issue.
-Note this layout is not comprehensive, for example only a few example "Priors" are shown.
+**Note** this layout is not comprehensive, for example only a few example "Priors" are shown.
diff --git a/README.rst b/README.rst
index 3628c06384f8475a3241a7e08443e5318a1fa28e..ac7dce89bcaf86e8afed971a58c3e10d59046cf3 100644
--- a/README.rst
+++ b/README.rst
@@ -22,7 +22,7 @@ If you need help, find an issue, or just have a question/suggestion you can
We encourage you to contribute to the development of bilby. This is done via a merge request. For
help in creating a merge request, see `this page
<https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html>`__ or contact
-us directly. For advice on contributing, see `this help page <https://git.ligo.org/lscsoft/bilby/blob/master/CONTRIBUTING.md>`__.
+us directly. For advice on contributing, see `the contributing guide<https://git.ligo.org/lscsoft/bilby/blob/master/CONTRIBUTING.md>`__.
--------------
diff --git a/bilby/core/sampler/pymc3.py b/bilby/core/sampler/pymc3.py
index 95a47bba07f41e40789b41642ceee743fab4d8c0..7a8745c8f9c1e5ad8555b3f951d26fd7b7c0c90f 100644
--- a/bilby/core/sampler/pymc3.py
+++ b/bilby/core/sampler/pymc3.py
@@ -484,7 +484,8 @@ class Pymc3(MCMCSampler):
args = step_kwargs.get(curmethod, {})
else:
args = {}
- self.kwargs['step'].append(pymc3.__dict__[step_methods[curmethod]](vars=[self.pymc3_priors[key]], **args))
+ self.kwargs['step'].append(
+ pymc3.__dict__[step_methods[curmethod]](vars=[self.pymc3_priors[key]], **args))
else:
curmethod = self.step_method[key].lower()
methodslist.append(curmethod)
@@ -503,7 +504,8 @@ class Pymc3(MCMCSampler):
args = step_kwargs.get(curmethod, {})
else:
args = {}
- self.kwargs['step'].append(pymc3.__dict__[step_methods[curmethod]](vars=[self.pymc3_priors[key]], **args))
+ self.kwargs['step'].append(
+ pymc3.__dict__[step_methods[curmethod]](vars=[self.pymc3_priors[key]], **args))
else:
with self.pymc3_model:
# check for a compound step list
diff --git a/bilby/core/utils.py b/bilby/core/utils.py
index afa2a9a4b7dcd08b265016b4f10f85072edb43bf..352670281d7d65e80cb71888985b7aa4169d3f19 100644
--- a/bilby/core/utils.py
+++ b/bilby/core/utils.py
@@ -926,10 +926,6 @@ class UnsortedInterp2d(interp2d):
def __call__(self, x, y, dx=0, dy=0, assume_sorted=False):
""" Wrapper to scipy.interpolate.interp2d which preserves the input ordering.
- See https://stackoverflow.com/questions/44941271/scipy-interp2d-returned-function-sorts-input-argument-automatically-and-undesira
- for the implementation details.
-
-
Parameters
----------
x: See superclass
@@ -1071,7 +1067,8 @@ def reflect(u):
"""
Iteratively reflect a number until it is contained in [0, 1].
- This is for priors with a reflective boundary condition, all numbers in the set `u = 2n +/- x` should be mapped to x.
+ This is for priors with a reflective boundary condition, all numbers in the
+ set `u = 2n +/- x` should be mapped to x.
For the `+` case we just take `u % 1`.
For the `-` case we take `1 - (u % 1)`.
diff --git a/examples/gw_examples/injection_examples/custom_proposal_example.py b/examples/gw_examples/injection_examples/custom_proposal_example.py
index 8480dd361a141b7407d7ab618028ad542d737cd1..afd85dace2ba9646388d0d5e1e19800679167010 100644
--- a/examples/gw_examples/injection_examples/custom_proposal_example.py
+++ b/examples/gw_examples/injection_examples/custom_proposal_example.py
@@ -51,10 +51,14 @@ likelihood = bilby.gw.GravitationalWaveTransient(
# proposal.
jump_proposals = proposal.JumpProposalCycle(
- [proposal.EnsembleWalk(priors=priors), proposal.EnsembleStretch(priors=priors),
- proposal.DifferentialEvolution(priors=priors), proposal.EnsembleEigenVector(priors=priors),
- bilby.gw.sampler.proposal.SkyLocationWanderJump(priors=priors), bilby.gw.sampler.proposal.CorrelatedPolarisationPhaseJump(priors=priors),
- bilby.gw.sampler.proposal.PolarisationPhaseJump(priors=priors), proposal.DrawFlatPrior(priors=priors)],
+ [proposal.EnsembleWalk(priors=priors),
+ proposal.EnsembleStretch(priors=priors),
+ proposal.DifferentialEvolution(priors=priors),
+ proposal.EnsembleEigenVector(priors=priors),
+ bilby.gw.sampler.proposal.SkyLocationWanderJump(priors=priors),
+ bilby.gw.sampler.proposal.CorrelatedPolarisationPhaseJump(priors=priors),
+ bilby.gw.sampler.proposal.PolarisationPhaseJump(priors=priors),
+ proposal.DrawFlatPrior(priors=priors)],
weights=[2, 2, 5, 1, 1, 1, 1, 1])
# Run cpnest with the proposals kwarg specified.
diff --git a/setup.cfg b/setup.cfg
index 6007f298b5da3e0d1d82e7f41ccce4e4abe18e27..a7a69fe9f033787df2a7eab72d3f56e6f3f6db48 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,6 +1,6 @@
[flake8]
exclude = .git,docs,build,dist,test,*__init__.py
-max-line-length = 160
+max-line-length = 120
ignore = E129 W504 W605
[tool:pytest]