Commit 61f72017 authored by Fabrice  ALLAIN's avatar Fabrice ALLAIN
Browse files

Merge branch '3-uniformization-of-docs-between-aria-and-conbox' into 'master'

Resolve "Uniformization of docs between ARIA and conbox"

Closes #3

See merge request bis-aria/ariaec!8
parents 6ccdabab 794f14ee
......@@ -3,6 +3,7 @@ examples*dev/
examples/tmp/
docs/olds/
*.simg
package-lock.json
################################################################################
# PYTHON #
......
This diff is collapsed.
......@@ -86,9 +86,9 @@ implementing features, refactoring code, porting to a different language),
otherwise you risk spending a lot of time working on something that the
project's developers might not want to merge into the project.
Please adhere to the coding conventions used throughout a project (indentation,
accurate docstring, coding and commit convention, etc.) and any other
requirements (such as test coverage).
**Please adhere to the [coding conventions][developers]** used
throughout the project (indentation, accurate docstring, coding and commit
convention, etc.) and any other requirements (such as test coverage).
Follow this process if you'd like your work considered for inclusion in the
project:
......@@ -144,76 +144,4 @@ project:
**IMPORTANT**: By submitting a patch, you agree to allow the project owner to
license your work under the same license as that used by the project.
## <a name="commits"></a> Git Commit Guidelines
We have very precise rules over how our git commit messages can be formatted. This leads to **more
readable messages** that are easy to follow when looking through the **project history**. But also,
we use the git commit messages to **generate the change log**.
The commit message formatting can be added using a typical git workflow or through the use of a CLI
wizard ([Commitizen](https://github.com/commitizen/cz-cli)). To use the wizard, run `yarn run commit`
in your terminal after staging your changes in git.
### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
The **header** is mandatory and the **scope** of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on GitHub as well as in various git tools.
### Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header
of the reverted commit.
In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit
being reverted.
A commit with this format is automatically created by the [`git revert`][git-revert] command.
### Type
Must be one of the following:
* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing or correcting existing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation
### Scope
The scope could be anything specifying place of the commit change. For example `$location`,
`$browser`, `$compile`, `$rootScope`, `ngHref`, `ngClick`, `ngView`, etc...
You can use `*` when the change affects more than a single scope.
### Subject
The subject contains succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end
### Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.
### Footer
The footer should contain any information about **Breaking Changes** and is also the place to
[reference GitHub issues that this commit closes][closing-issues].
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
The rest of the commit message is then used for this.
A detailed explanation can be found in this [document][commit-message-format].
[developers]: DEVELOPERS.md
\ No newline at end of file
# Developing conventions
* [Running Tests](#tests)
* [Coding Rules](#rules)
* [Commit Message Guidelines](#commits)
* [Writing Documentation](#documentation)
This document describes how to set up your development environment to build, test and
explains the basic mechanics and conventions adopted since version 0.1.
## <a name="tests"></a> Running Tests
### <a name="unit-tests"></a> Running the Unit Test Suite
We write mostly doctest and execute them with pytest runner. To run all of the
tests once run:
```shell
pytest -sx --doctest-modules --doctest-ignore-import-errors
```
## <a name="rules"></a> Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you are working:
* All features or bug fixes **must be tested** by one or more [specs][unit-testing].
* All public API methods **must be documented** with docstring. To see how we
document our APIs, please check out the existing source code and see the section about [writing documentation](#documentation).
Usually, each docstring follows the rules from [Numpy docstring Guide][np-style-guide]
## <a name="commits"></a> Git Commit Guidelines
We have very precise rules over how our git commit messages can be formatted. This leads to **more
readable messages** that are easy to follow when looking through the **project history**. But also,
we use the git commit messages to **generate the change log**.
The commit message formatting can be added using a typical git workflow or through the use of a CLI
wizard.
### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
The **header** is mandatory and the **scope** of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on GitHub as well as in various git tools.
### Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header
of the reverted commit.
In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit
being reverted.
A commit with this format is automatically created by the [`git revert`][git-revert] command.
### Type
Must be one of the following:
* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing or correcting existing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation
### Scope
The scope could be anything specifying place of the commit change. For example `conbox`,
`legacy`, `scientific`, etc...
You can use `*` when the change affects more than a single scope.
### Subject
The subject contains succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end
### Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.
### Footer
The footer should contain any information about **Breaking Changes** and is also the place to
[reference Gitlab issues that this commit closes][closing-issues].
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
The rest of the commit message is then used for this.
## <a name="documentation"></a> Writing Documentation
All the documentation files are stored in the ``docs`` folder where every
file can be manually changed (except for ``docs/api`` folder which is
automatically generated).
This means that since we generate the documentation from the source code, we can easily provide
version-specific documentation by simply checking out a version of the package and running the build.
Extracting the source code documentation, processing and building the docs is handled by the
documentation generation tool [Sphinx][sphinx] combined with [better-apidoc][better-apidoc].
### Building and viewing the docs locally
The docs can be built from scratch using the makefile in docs:
```shell
cd docs
make html
```
### General documentation with Markdown
Any text in tags can contain markdown syntax for formatting. Generally, you can use any markdown
feature.
#### Headings
Only use *h2* headings and lower, as the page title is set in *h1*. Also make sure you follow the
heading hierarchy. This ensures correct table of contents are created.
#### Code blocks
In line code can be specified by enclosing the code in back-ticks (\`).
A block of multi-line code can be enclosed in triple back-ticks (\`\`\`) but it is formatted better
if it is enclosed in &lt;pre&gt;...&lt;/pre&gt; tags and the code lines themselves are indented.
[closing-issues]: https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html
[git-revert]: https://git-scm.com/docs/git-revert
[git-setup]: https://help.github.com/articles/set-up-git
[Sphinx]: http://www.sphinx-doc.org/en/master/
[better-apidoc]: https://github.com/goerz/better-apidoc
\ No newline at end of file
......@@ -3,10 +3,17 @@ MAINTAINER Fabrice Allain <fabrice.allain@pasteur.fr>
RUN yum install -y epel-release
RUN yum install -y python2-pip python-devel gcc make git
RUN curl --silent --location https://rpm.nodesource.com/setup_8.x | bash -; yum -y install nodejs
RUN npm install -g --save-dev @commitlint/{cli,config-conventional}; npm install -g conventional-changelog-cli
RUN echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js
RUN pip install --upgrade pip ; pip install --upgrade setuptools; pip install sphinx; pip install numpy; pip install matplotlib; pip install coverage; pip install pytest; pip install pytest-cov
RUN wget http://www2.ccpn.ac.uk/download/ccpnmr/analysis2.4.2.tar.gz; tar xvzf analysis2.4.2.tar.gz; export CCPNMR_TOP_DIR=$(pwd)/ccpnmr; export PYTHONPATH=${PYTHONPATH}:$CCPNMR_TOP_DIR/ccpnmr2.4/python
RUN mkdir build-aria
ADD aria /build-aria/aria
ADD *.py PKG-INFO /build-aria/
RUN cd build-aria && pip install .
\ No newline at end of file
RUN cd build-aria && pip install .; npm install --save-dev husky
RUN npx yarn add husky --dev
Version: 0.0.18
\ No newline at end of file
Version: 0.0.20
\ No newline at end of file
......@@ -21,7 +21,7 @@ de Novo Ambiguous Restraints for Iterative Assignment
:alt: DOI status
``ariaec`` is a Python_ library that provides *de novo* structure prediction
**ariaec** is a Python_ library that provides *de novo* structure prediction
based on ARIA_ pipeline and evolutionary restraints inferred from co-evolution.
......@@ -37,20 +37,13 @@ Quick Start
Be sure to check if the following packages are correctly installed with
your python installation or virtual environment.
* ``pip`` (>= 9.0)
* ``setuptools`` (>= 18.0)
* ``numpy`` (>= 1.11)
* **pip** (>= 9.0)
* **setuptools** (>= 18.0)
* **numpy** (>= 1.11)
Then the easiest solution is to call the ``pip`` command below :
Then the easiest solution is to call the **pip** command below :
.. code-block:: console
$ pip install git+https://gitlab.pasteur.fr/bis-aria/ariaec
Another possibility is to download the ZIP_ or TAR_ version from Gitlab_,
extract the files and run ``pip install .`` inside the new directory
``pip install git+https://gitlab.pasteur.fr/bis-aria/ariaec``
For more information about installation and usage, please refer to the
`ARIAEC documentation <http://bis-aria.pages.pasteur.fr/ariaec>`_.
......
# coding=utf-8
"""
ARIA -- Ambiguous Restraints for Iterative Assignment
A software for automated NOE assignment
Version 2.3
Copyright (C) Benjamin Bardiaux, Michael Habeck, Therese Malliavin,
Wolfgang Rieping, and Michael Nilges
All rights reserved.
NO WARRANTY. This software package is provided 'as is' without warranty of
any kind, expressed or implied, including, but not limited to the implied
warranties of merchantability and fitness for a particular purpose or
a warranty of non-infringement.
Distribution of substantively modified versions of this module is
prohibited without the explicit permission of the copyright holders.
$Author: bardiaux $
$Revision: 1.1.1.1 $
$Date: 2010/03/23 15:27:24 $
.. .......................................................................... ..
.. ARIA -- Ambiguous Restraints for Iterative Assignment ..
.. ..
.. A software for automated NOE assignment ..
.. ..
.. Version 2.3 ..
.. ..
.. ..
.. Copyright (C) Benjamin Bardiaux, Michael Habeck, Therese Malliavin, ..
.. Wolfgang Rieping, and Michael Nilges ..
.. ..
.. All rights reserved. ..
.. ..
.. NO WARRANTY. This software package is provided 'as is' without warranty of ..
.. any kind, expressed or implied, including, but not limited to the implied ..
.. warranties of merchantability and fitness for a particular purpose or ..
.. a warranty of non-infringement. ..
.. ..
.. Distribution of substantively modified versions of this module is ..
.. prohibited without the explicit permission of the copyright holders. ..
.. ..
.. $Author: bardiaux $ ..
.. $Revision: 1.1.1.1 $ ..
.. $Date: 2010/03/23 15:27:24 $ ..
.. .......................................................................... ..
"""
import re
......
#!/usr/bin/env python
# coding=utf-8
"""
ARIA -- Ambiguous Restraints for Iterative Assignment
A software for automated NOE assignment
Version 2.3
Copyright (C) Benjamin Bardiaux, Michael Habeck, Therese Malliavin,
Wolfgang Rieping, and Michael Nilges
All rights reserved.
NO WARRANTY. This software package is provided 'as is' without warranty of
any kind, expressed or implied, including, but not limited to the implied
warranties of merchantability and fitness for a particular purpose or
a warranty of non-infringement.
Distribution of substantively modified versions of this module is
prohibited without the explicit permission of the copyright holders.
$Author: bardiaux $
$Revision: 1.1.1.1 $
$Date: 2010/03/23 15:27:16 $
.. .......................................................................... ..
.. ARIA -- Ambiguous Restraints for Iterative Assignment ..
.. ..
.. A software for automated NOE assignment ..
.. ..
.. Version 2.3 ..
.. ..
.. ..
.. Copyright (C) Benjamin Bardiaux ..
.. Structural Bioinformatics, Institut Pasteur, Paris ..
.. ..
.. All rights reserved. ..
.. ..
.. NO WARRANTY. This software package is provided 'as is' without warranty of ..
.. any kind, expressed or implied, including, but not limited to the implied ..
.. warranties of merchantability and fitness for a particular purpose or ..
.. a warranty of non-infringement. ..
.. ..
.. Distribution of substantively modified versions of this module is ..
.. prohibited without the explicit permission of the copyright holders. ..
.. ..
.. $Author: bardiaux $ ..
.. $Revision: 1.1.1.1 $ ..
.. $Date: 2010/03/23 15:27:24 $ ..
.. .......................................................................... ..
"""
from __future__ import absolute_import, division, print_function
from future.builtins import input
......
#!/usr/bin/env python
# coding=utf-8
"""
ARIA -- Ambiguous Restraints for Iterative Assignment
A software for automated NOE assignment
Version 2.3
Copyright (C) Benjamin Bardiaux, Michael Habeck, Therese Malliavin,
Wolfgang Rieping, and Michael Nilges
All rights reserved.
NO WARRANTY. This software package is provided 'as is' without warranty of
any kind, expressed or implied, including, but not limited to the implied
warranties of merchantability and fitness for a particular purpose or
a warranty of non-infringement.
Distribution of substantively modified versions of this module is
prohibited without the explicit permission of the copyright holders.
$Author: bardiaux $
$Revision: 1.1.1.1 $
$Date: 2010/03/23 15:27:16 $
.. .......................................................................... ..
.. ARIA -- Ambiguous Restraints for Iterative Assignment ..
.. ..
.. A software for automated NOE assignment ..
.. ..
.. Version 2.3 ..
.. ..
.. ..
.. Copyright (C) Benjamin Bardiaux ..
.. Structural Bioinformatics, Institut Pasteur, Paris ..
.. ..
.. All rights reserved. ..
.. ..
.. NO WARRANTY. This software package is provided 'as is' without warranty of ..
.. any kind, expressed or implied, including, but not limited to the implied ..
.. warranties of merchantability and fitness for a particular purpose or ..
.. a warranty of non-infringement. ..
.. ..
.. Distribution of substantively modified versions of this module is ..
.. prohibited without the explicit permission of the copyright holders. ..
.. ..
.. $Author: bardiaux $ ..
.. $Revision: 1.1.1.1 $ ..
.. $Date: 2010/03/23 15:27:24 $ ..
.. .......................................................................... ..
"""
......
......@@ -260,8 +260,7 @@ class AriaEcCommands(object):
parser.add_argument("seq", help="sequence file [FASTA]",
action=ReadableFile)
parser.add_argument("msa", nargs='?',
help="MSA [FASTA] for diversityvalue"
"used with bbcontacts")
help="MSA [FASTA] used to compute diversityvalue ")
parser.add_argument("-t", "--type", required=True, dest="contact_type",
choices=self.contact_types, help="Infile contact "
"type")
......
......@@ -36,7 +36,7 @@ default_cutoff: 8.0
;ca_ca:
;cb_cb:
;sc_sc:
bool
[setup]
; ------------------------------ TBL parameters ------------------------------ #
; longrange_hb : True, False [False]
......@@ -150,7 +150,7 @@ nd_alpha: 1.0
runid: 1
cpus: 100
host_command: "sbatch -t 02:00:00"
host_executable: bin/cns1.21_aria_logn_linux_x86_64_intel.exe
host_executable:
temp_root: examples/tmp
parameter_definition: automatic
ss_dist_format: tbl
......@@ -166,7 +166,7 @@ dist_calibrate: no
dist_run_network_anchoring: no
dist_filter_contributions: yes
dist_avg_exponent: 6
cns_executable: bin/cns1.21.exe
cns_executable:
cns_keep_output: no
unambiguous_restraints_k_cool1_initial: 10.0
unambiguous_restraints_k_cool1_final: 50.0
......
......@@ -16,32 +16,27 @@ def net_deconv(npmat, beta=0.99, alpha=1, control=0):
This is a python implementation/translation of network deconvolution by
MIT-KELLIS LAB
LICENSE: MIT-KELLIS LAB
LICENSE: MIT-KELLIS LAB
AUTHORS:
AUTHORS:
Algorithm was programmed by Soheil Feizi.
Paper authors are S. Feizi, D. Marbach, M. Medard and M. Kellis
Python implementation: Gideon Rosenthal
REFERENCES:
For more details, see the following paper:
For more details, see the following paper:
Network Deconvolution as a General Method to Distinguish
Direct Dependencies over Networks
By: Soheil Feizi, Daniel Marbach, Muriel Medard and Manolis Kellis
Nature Biotechnology
--------------------------------------------------------------------------
ND.m: network deconvolution
--------------------------------------------------------------------------
DESCRIPTION:
USAGE:
mat_nd = ND(npmat)
mat_nd = ND(npmat,beta)
mat_nd = ND(npmat,beta,alpha,control)
USAGE:
mat_nd = ND(npmat)
mat_nd = ND(npmat,beta)
mat_nd = ND(npmat,beta,alpha,control)
INPUT ARGUMENTS:
......
......@@ -10,7 +10,7 @@ import csv
import datetime
import itertools
import logging
import matplotlib
import matplotlib; matplotlib.use("Agg")
import numpy as np
import operator
import os
......@@ -30,7 +30,7 @@ from ..core.legacy import AminoAcid as AminoAcid
from .common import (tickmin, tickrot, titleprint, addtup)
from .ndconv import net_deconv
matplotlib.use("Agg", warn=False)
LOG = logging.getLogger(__name__)
# TODO: check dataframe symmetry or always use unstack
# TODO: objet MapContainer contenant les differentes maps en attributs ! (et
......@@ -44,6 +44,7 @@ class Map(pd.DataFrame):
Examples
--------
Score/distance matrix
>>> d = Map(index=[0,1,2], columns=[0,1,2])
>>> d
0 1 2
......@@ -363,7 +364,7 @@ class ProteinMap(Map):
@property
def contact_flags(self):
return self._contact_flags
return self._evflags
def create_heatmap(self):
"""
......@@ -502,7 +503,7 @@ class ProteinMap(Map):
Returns
-------
"""
plotpath = os.path.join(outdir, "%s.maplot.%s" % (
outprefix, plot_ext))
......@@ -564,23 +565,18 @@ class ProteinMap(Map):
def compareplot(self, protmap, save_fig=True, alpha=None, **kwargs):
"""
Compare 2 contact map and plot differences
Compare 2 contact map and plot the differences
Parameters
----------
protmap :
param save_fig:
alpha :
param kwargs: (Default value = None)
save_fig :
(Default value = True)
**kwargs :
alpha :
kwargs :
Returns
-------
"""
self.plotflush()
# Contact map plot
......@@ -983,23 +979,13 @@ class ResAtmMap(ProteinMap):
"""
Protein distance/contact matrix for all atom pairs. If no sequence given,
protein distance/contact matrix for all amino acids
Ex:
residue PHE1 \
atom CD1 CD2 CB CA CG CZ
residue atom
PHE1 CD1 0.000000 2.394145 2.455440 3.269219 1.391024 2.421148
CD2 2.394145 0.000000 2.509243 3.407996 1.379875 2.401098
CB 2.455440 2.509243 0.000000 1.507025 1.478053 4.267602
CA 3.269219 3.407996 1.507025 0.000000 2.505414 5.085997
CG 1.391024 1.379875 1.478053 2.505414 0.000000 2.790403
Parameters
Attributes
----------