Skip to content
Snippets Groups Projects
Commit 2f33e62c authored by Vermaat's avatar Vermaat
Browse files

Move to Sphinx for developer documentation 

This is quite a large commit, touching many things related to developer
documentation. It is all focussed on getting as much of this as possible
into the new Sphinx-based documentation.

Some highlights:

- Start Sphinx-based developer documentation, including fairly complete
  instructions for installation and configuration.
- Remove epydoc API docs.
- Rework some docstrings to conform to reStructuredText, so they can be
  used in the API docs generated by Sphinx.
- Move all of the top-level text files to reStructuredText so they can
  linked from the Sphinx-based docs and for consistency.
- Remove many obsolete things from the extras/ directory, including old
  installation scripts and migrations.

Many of the installation related documentation and scripts are removed
or adapted in light of the new automated deployment using Ansible.
parent 47d5633b
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1403 additions and 605 deletions
AUTHORS deleted 100644 → 0
+ 0
− 8
View file @ 47d5633b
Leiden University Medical Center department of Human Genetics <humgen@lumc.nl>
Jeroen Laros <j.f.j.laros@lumc.nl>
Martijn Vermaat <martijn@vermaat.name>
Jonathan Vis <jvis@liacs.nl>
Gerben Stouten <gstouten@gmail.com>
Gerard Schaafsma <g.c.p.schaafsma@lumc.nl>
Daria Dvorkina <dasha@dvorkina.ru>
Alisa Muraveva <alisa391213725@yandex.ru>
AUTHORS.rst 0 → 100644
+ 23
− 0
View file @ 2f33e62c
Mutalyzer 2 is designed and developed by Jeroen F.J. Laros at the department
of Human Genetics at Leiden University Medical Center where it is currently
maintained by Martijn Vermaat.
The following people have worked on developing Mutalyzer:
- Jeroen Laros
- Martijn Vermaat
- Jonathan Vis
- Gerben Stouten
- Gerard Schaafsma
- Daria Dvorkina
- Alisa Muraveva
Specifications are given by Peter E.M. Taschner and Johan T. den Dunnen.
Furthermore we would like to thank the following people for their valuable
work on previous versions that acted as a guideline for the development of the
current version:
- Ernest van Ophuizen
- Martin Wildeman
- Corinne Bareil
CHANGES.rst 0 → 100644
+ 290
− 0
View file @ 2f33e62c
Changelog
=========
This is a record of changes made between each Mutalyzer release.
Version 2.0.beta-31
-------------------
Release date to be decided.
Version 2.0.beta-30
-------------------
Released on February 18th 2014.
- Handle NCBI Entrez response validation errors (fixes, among other things,
`LOVD#29 <https://humgenprojects.lumc.nl/trac/LOVD3/ticket/29>`_).
- Loosen error severity when CDS cannot be translated.
- Mutalyzer development migrated from Subversion to Git for version control.
Version 2.0.beta-29
-------------------
Released on October 11th 2013.
- Add Jonathan Vis attribution and COMMIT logo to about page.
Version 2.0.beta-28
-------------------
Released on September 18th 2013.
- Enable the HTTP/RPC+JSON web service to be used with POST requests.
Version 2.0.beta-27
-------------------
Released on June 18th 2013.
- Fix caching transcript-protein links from NCBI, reducing impact of NCBI
communication problems.
Version 2.0.beta-26
-------------------
Released on April 9th 2013.
- Added mm10 (Mouse) transcript mappings to position converter.
- LRG parser updated to LRG 1.7 schema (`#127
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/127>`_).
Version 2.0.beta-25
-------------------
Released on March 25th 2013.
- Detect incorrect exon annotation in transcript references.
- Move documentation to Trac.
- Exon table is included in `runMutalyzer` webservice results.
- Temporarily disable frameshift detection in experimental description
extractor (`#124
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/124>`_).
- Allow selectors on transcript references in position converter.
- Syntax checker now supports protein level variant descriptions.
Version 2.0.beta-24
-------------------
Released on December 10th 2012.
- Rename some warning codes (webservice API) (`#98
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/98>`_).
- Variants on mtDNA in position converter.
Version 2.0.beta-23
-------------------
Released on November 8th 2012.
No user-visible changes.
Version 2.0.beta-22
-------------------
Released on November 2nd 2012.
- Submitting batch jobs via the web services (`#115
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/115>`_).
- Allow for leading whitespace in batch job input (`#107
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/107>`_).
- New `descriptionExtract` webservice function.
- Name checker now includes description extractor output as an experimental
service.
- Slice chromosome by gene name in reference file loader is now case
insensitive (`#118
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/118>`_).
- Warn on missing positioning scheme (`#114
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/114>`_).
Version 2.0.beta-21
-------------------
Released on July 23rd 2012.
- Support compound variants in position converter.
- Support non-coding transcripts in position converter (`#102
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/102>`_).
- Move to new RPC library version, causing slight change in HTTP/RPC+JSON
webservice output (more wrappers around output), but fixes #104.
- Fix position converter for delins with explicit deleted sequence.
- Fix description update from Version 2.0.beta-20 to use- notation instead of
counting.
Version 2.0.beta-20
-------------------
Released on July 21st 2012.
- Disabled the ``-u`` and ``+d`` convention in favour of the official HGVS
recommendations.
Version 2.0.beta-19
-------------------
Released on June 21st 2012.
- Fix crash on inversions (`#99
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/99>`_).
Version 2.0.beta-18
-------------------
Released on June 7th 2012.
- Moved from soaplib to rpclib for webservices (`#66
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/66>`_).
- Added HTTP/RPC+JSON webservice (`#18
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/18>`_).
- Fixed name checker errors in some adjacent variants (`#83
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/83>`_).
- Name checker form now uses GET requests to support easier linking to result
pages.
- You can now specify chromosomes by name in the reference file loader (`#92
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/92>`_).
- Made batch daemon not crash on MySQL restarts (`#91
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/91>`_).
- Position converter now detects incorrect order in position ranges (`#95
<https://humgenprojects.lumc.nl/trac/mutalyzer/ticket/95>`_).
- Added NBIC logo to 'about' page.
Version 2.0.beta-17
-------------------
Released on April 2nd 2012.
- Fixed crossmapping bug for some transcripts.
- Fixes for NCBI Entrez EFetch Version 2.0 release.
- Better chromosomal variant descriptions.
- Various smaller features and bugfixes.
Version 2.0.beta-16
-------------------
Released on March 1st 2012.
- Fixed position converter mapping info for some transcripts.
- Fixed deletion with deleted sequence length as argument.
Version 2.0.beta-15
-------------------
Released on February 20th 2012.
- Added 'Description Extractor' (see the main menu).
- Fixes for NCBI Entrez EFetch Version 2.0 release.
- Added chromosomal positions to `getTranscriptsAndInfo` webservice.
- Fixed chromosome slicing on reverse complement
- Fixed describing NOP variants with ``=``.
- Added Reference sequence info in `runMutalyzer` SOAP function response.
- Fixed mapping info for genes mapped to more than one chromosome.
- Various smaller features and bugfixes.
Version 2.0.beta-14
-------------------
Released on January 26th 2012.
- Added a SOAP service `getTranscriptsMapping`.
- Various smaller features and bugfixes.
Version 2.0.beta-13
-------------------
Released on January 25th 2012.
- Accept EX positioning scheme.
- Fix handling of LRG reference sequences.
- Various smaller features and bugfixes.
Version 2.0.beta-12
-------------------
Released on November 25th 2011.
- Accept plasmid reference sequences.
- View variant position in UCSC Genome Browser (only for transcript
references).
- Retry querying dbSNP if it does not respond the first time.
- Support reference GenBank files built from contigs.
- Add optional argument to SOAP service `numberConversion` to map chromosomal
locations to any gene.
- Various smaller features and bugfixes.
Version 2.0.beta-11
-------------------
Released on September 30st 2011.
- Major code refactoring:
- Mutalyzer is now structured as a proper Python package.
- Reworked installation and upgrade procedure.
- Remote installation using Fabric.
- Batch scheduler is now a proper system daemon.
- Use mod_wsgi (with web.py) instead of the deprecated mod_python.
- Added a lot of internal documentation.
- Introduce unit tests.
- Handle deletions of entire exons.
- Added a SOAP service `info`.
- Handle unknown (fuzzy) intronic positions.
- Automatic synchronization of database and cache between Mutalyzer
installations.
- Use NCBI instead of UCSC for transcript mapping info.
- Added a SOAP service `getdbSNPDescriptions`.
- Moved Trac and Subversion repository to new server.
- Implement HTTP HEAD method for ``/Reference/*`` locations.
- Added a SOAP service `ping`.
- Added an optional versions parameter to the SOAP service `getTranscripts`.
- Various smaller features and bugfixes.
Version 2.0.beta-10
-------------------
Released on July 21st 2011.
- Greatly reduce runtime for large batch jobs.
Version 2.0.beta-9
------------------
Released on June 27th 2011.
- Reworked the calculation of new splice site positions.
- Optionally restrict SOAP service `getTranscriptsAndInfo` transcripts to a
gene.
- Add raw variants to SOAP service `runMutalyzer` results.
- Provide webservice client examples.
- Various smaller features and bugfixes.
Older versions
--------------
The first lines of code for Mutalyzer 2.0 where written July 28th 2009, and
version 2.0.beta-8 was released on January 31st 2011. As far as Mutalyzer 1 is
concerned, archaeology is not really our field of research.
DEVELOPMENT.md deleted 100644 → 0
+ 0
− 232
View file @ 47d5633b
Mutalyzer development
=====================
Development of Mutalyzer happens on the GitLab server:
https://git.lumc.nl/mutalyzer/mutalyzer
Coding style
------------
In general, try to follow the [PEP 8](http://www.python.org/dev/peps/pep-0008)
guidelines for Python code and
[PEP 257](http://www.python.org/dev/peps/pep-0257/) for docstrings.
Unit tests
----------
The unit tests depend on a running batch daemon, webserver, and SOAP
web service:
sudo /etc/init.d/mutalyzer-batchd start
sudo /etc/init.d/apache2 start
Now run the tests with:
nosetests -v
Or, if you are in a hurry, skip the long-running tests with:
MUTALYZER_QUICK_TEST=1 nosetests -v
Working with feature branches
-----------------------------
New features are best implemented in their own branches, isolating the work
from unrelated developments. In fact, it's good practice to **never work
directly on the master branch** but always in a separate branch. For this
reason, the master branch on the GitLab server is locked. Feature branches can
be merged back into master via a **merge request** in GitLab.
Before starting work on your feature, create a branch for it:
git checkout -b your-feature
Commit changes on this branch. If you're happy with it, push to GitLab:
git push origin your-feature -u
Now create a merge request to discuss the implementation with your
colleagues. This might involve adding additional commits which are included in
the merge request by pushing your branch again:
git commit
git push
You may also be asked to rebase your branch on the master branch if it has
changed since you started your work. This will require a forced push:
git fetch
git rebase origin/master
git push -f
If the work is done, a developer can merge your branch and close the merge
request. After the branch was merged you can safely delete it:
git branch -d your-feature
Release management
------------------
The current Mutalyzer version is recorded in `mutalyzer/__init__.py`. See the
comments in that file for more info of the versioning scheme.
On the event of a new release, the following is done:
emacs mutalyzer/__init__.py
Update `__date__`, remove `dev` from `__version_info__` and set `RELEASE` to
`True`.
git commit -am 'Bump version to 2.0.beta-XX'
git tag -a 'mutalyzer-2.0.beta-XX'
git push --tags
emacs mutalyzer/__init__.py
Set `__version_info__` to a new version ending with `'dev'` and set `RELEASE`
to `FALSE`.
git commit -am 'Open development for 2.0.beta-YY'
Be sure to upgrade your installations to the new version as described in the
INSTALL file (e.g. `sudo python setup.py develop` for development checkouts).
Development notes
-----------------
Todo list:
- Improve the web interface design :)
- Test all uses of mkstemp().
- Use naming conventions for modules Crossmap, Db, File, GenRecord, Retriever
and Scheduler.
- Use standard logging module, with rotating functionality. Race conditions
on the log file are probably a problem in the current setup.
Instead of that rotating, we could also use logrotate:
http://serverfault.com/questions/55610/logrotate-and-open-files
- Setup continuous integration. Currently, I'm most impressed with Hudson.
http://hudson-ci.org/
http://www.rhonabwy.com/wp/2009/11/04/setting-up-a-python-ci-server-with-hudson/
Or perhaps Jenkins.
http://jenkins-ci.org/
- Migrate Javascript to JQuery.
- I think in the long run, the Output object is not really the way to go. It
obscures the control flow. The logging part should use the standard logging
module. The data gathering by the Output object is probably better handled
by explicitely returning data objects from functions.
- Migrate from TAL to a more mondern and maintained Python template library,
for example jinja.
- Develop a large test suite.
- Create a web interface url to watch the progress of a batch job.
- Create web services for the batch jobs (steal ideas from Jeroen's DVD
web service).
- Use virtualenv?
- Use SQLAlchemy?
- Password for MySQL user.
- In deployment, remove old versions of Mutalyzer package?
- Check for os.path.join vulnerabilities.
- Use a standard solution for the database migrations in extras/migrations.
- Use something like Sphinx to generate development documentation from code.
- There are some problems with the batch architecture, especially that there
cannot be multiple workers without synchronisation problems.
Good read: http://news.ycombinator.com/item?id=3002861
Suggestion: http://celeryproject.org/
- Have a normal 404 page.
- Maintenance (and/or read-only) mode.
- Cleanup this document.
- Be more explicit in all the type of descriptions we don't currently support.
Code style guide:
- Follow PEP 8 (code) and PEP 257 (docstrings).
http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0257/
Read the Google Python Style guide:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
- Use Epydoc style documentation in docstrings.
- End class and method definitions with their name as comment.
- Executables are in the bin/ directory.
- For examples, check established Python projects:
http://code.djangoproject.com/browser/django/trunk
http://twistedmatrix.com/trac/browser/trunk
https://github.com/webpy/webpy
https://github.com/mitsuhiko/jinja2
https://bitbucket.org/mramm/tg-21/src
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files
https://github.com/ask/celery
- A lot of code does not yet adhere to these points, this is an ongoing
effort.
Obsoleted features:
- On eu.liacs.nl:
/etc/apache2/mods-enabled/rewrite.load contains a rewrite rule that converts
"Variant_info.php" to "Variant_info".
When all LOVD versions are above 2.0-23, this rule can be deleted and the
rewrite module can be disabled.
- In the Variant_info() function a substitution on error messages is
performed.
When all LOVD versions are above 2.0-23, this check can be deleted.
Dependencies
------------
Mutalyzer depends on the following (Debian/Ubuntu) packages:
- mysql-server >= 5.1
- python >= 2.6
- python-mysqldb >= 1.2.2
- python-biopython >= 1.54
- python-pyparsing >= 1.5.0
- python-configobj >= 4.4.0
- python-magic >= 5.04-2
- python-psutil >= 0.1.3-1
- python-xlrd >= 0.6.1-2
- python-daemon >= 1.5.5
- python-soappy >= 0.12.0-2
- python-suds >= 0.3.9-1
The web and SOAP interfaces depend on the following packages:
- apache2 >= 2.2.11
- libapache2-mod-wsgi >= 2.8
- python-webpy >= 0.33
- python-rpclib >= 2.8.0-beta
- python-simpletal >= 4.1-6
Automatic remote deployment depends on Fabric:
- fabric >= 0.9.0-2
The unit tests depend on the following packages:
- python-nose >= 0.11
- python-webtest >= 1.2.3
As of 2011-08-23, snakefood reports the following imports from the Mutalyzer
source code (excluding the standard library imports):
Bio
MySQLdb
SOAPpy
configobj
daemon
fabric
lockfile
lxml
magic
nose
pyparsing
setuptools
simpletal
rpclib
suds
web
webtest
xlrd
INSTALL.md deleted 100644 → 0
+ 0
− 156
View file @ 47d5633b
Mutalyzer installation instructions
===================================
Default configuration notes
---------------------------
The instructions in this file are quite specific to the standard Mutalyzer
environment. This consists of a Debian stable (Squeeze) system with Apache
and Mutalyzer using its mod_wsgi module. Debian conventions are used
throughout.
The following is an overview of default locations used by Mutalyzer:
Package files /usr/local/lib/python2.6/dist-packages/...
Configuration /etc/mutalyzer/config
Log file /var/log/mutalyzer.log
Cache directory /var/cache/mutalyzer
Batchd init script /etc/init.d/mutalyzer-batchd
Mapping update crontab /etc/cron.d/mutalyzer-mapping-update
Apache configuration /etc/apache2/conf.d/mutalyzer.conf
Static website files /var/www/mutalyzer/base
The default database user is 'mutalyzer' with no password and the database
names are 'mutalyzer', 'hg18', and 'hg19'.
By default, Mutalyzer is exposed under the '/mutalyzer' url by Apache.
All Mutalyzer processes run under the www-data user and files created and/or
modified by Mutalyzer are owned by this user.
If you have a different environment, or want to customize the default
locations, you can read through these instructions and modify them to your
needs.
Short version
-------------
Run the following commands:
git clone https://git.lumc.nl/mutalyzer/mutalyzer
cd mutalyzer
sudo bash extras/pre-install.sh
sudo python setup.py install
sudo bash extras/post-install.sh
sensible-browser http://localhost/mutalyzer
Or follow the more detailed instructions below.
Automated deployment on a remote host
-------------------------------------
For deploying Mutalyzer on a remote (production or testing) host, we recommend
to automate the steps described below by using Fabric and the included
fabfile. You need Fabric installed on your local machine:
easy_install fabric
To do a deployment on a server with an existing configured Mutalyzer
installation:
fab deploy -H server1.mutalyzer.nl
To do a fresh deployment on a new server:
fab deploy:boostrap=yes -H server1.mutalyzer.nl
Get Mutalyzer
-------------
Since you are reading this, you can probably skip this step. Otherwise, get
your hands on a tarball and:
tar -zxvf mutalyzer-XXX.tar.gz
cd mutalyzer-XXX
Or get the source from GitLab directly:
git clone https://git.lumc.nl/mutalyzer/mutalyzer
cd mutalyzer
Install dependencies
--------------------
If you are on Debian or Ubuntu, you can use the following command to install
all dependencies:
sudo bash extras/pre-install.sh
Otherwise, install them manually (perhaps have a look in the above script for
a useful dependency list).
Install Mutalyzer
-----------------
Mutalyzer can be installed using Python setuptools. For a production
environment:
sudo python setup.py install
Alternatively, if you want to have a development environment, use:
sudo python setup.py develop
The development environment uses symlinks to this source directory, so you can
develop directly from here. This command should be re-issued whenever the
version number of Mutalyzer is updated.
Setup Mutalyzer
---------------
This step creates configuration files and populates the database:
sudo bash extras/post-install.sh
You can now edit /etc/mutalyzer/config and /etc/apache2/conf.d/mutalyzer.conf
to your likings.
Test the installation
---------------------
You should always test the installation. The tests (for now at least) need
the batch daemon and the webserver (the SOAP part) running.
Now run the tests:
nosetests
Upgrade Mutalyzer
-----------------
Unless you installed Mutalyzer in a development environment as described
above, you can upgrade Mutalyzer to a new version by running from the source
directory:
sudo python setup.py install
sudo bash extras/post-upgrade.sh
If you installed Mutalyzer in a development environment, you don't have to
do anything usually, except for the following situations.
* If the database has changed, run:
for M in extras/migrations/*.migration; do sudo $M migrate; done
* If the Mutalyzer version has changed, run:
sudo python setup.py develop
\ No newline at end of file
LICENSE.rst 0 → 100644
+ 5
− 0
View file @ 2f33e62c
Copyright (c) 2009-2014 by Leiden University Medical Center and contributors
(see AUTHORS for details).
Mutalyzer does currently not come with a license. Please contact the authors
if you need one.
MANIFEST.in
+ 1
− 1
View file @ 2f33e62c
include AUTHORS README.md
include AUTHORS.rst CHANGES.rst LICENSE.rst README.rst
recursive-include mutalyzer/website/templates *
README.md deleted 100644 → 0
+ 0
− 26
View file @ 47d5633b
Mutalyzer, an HGVS variant nomenclature checker
===============================================
The canonical Mutalyzer installation can be found at https://mutalyzer.nl
Documentation and issue tracker
-------------------------------
See the doc directory for (possibly outdated) developer documentation and
presentation slides related to Mutalyzer. See the
[Mutalyzer Trac](https://humgenprojects.lumc.nl/trac/mutalyzer) for user
documentation and issue tracker.
Installation
------------
See the INSTALL.md file for installation instructions.
Development
-----------
The DEVELOPMENT.md file has more information for developers working on
Mutalyzer.
README.rst 0 → 100644
+ 27
− 0
View file @ 2f33e62c
Mutalyzer
=========
Mutalyzer is an HGVS variant nomenclature checker. The canonical Mutalyzer
installation can be found at [mutalyzer.nl](https://mutalyzer.nl).
Documentation
-------------
User documentation can be found on the `wiki
<https://humgenprojects.lumc.nl/trac/mutalyzer>`_. From there, you can also
submit bug reports and feature requests.
Developer documentation can be found in the ``doc/`` subdirectory and can be
compiled to HTML by running ``make html`` from there. This requires `Sphinx`_
to be installed.
Copyright
---------
Mutalyzer does currently not come with a license. Please contact the authors
if you need one. See the AUTHORS.rst file for a list of authors.
.. _Sphinx: http://sphinx-doc.org/
doc/.gitignore 0 → 100644
+ 1
− 0
View file @ 2f33e62c
/.build
doc/.static/.gitignore 0 → 100644
+ 0
− 0
View file @ 2f33e62c
doc/API/api.conf deleted 100644 → 0
+ 0
− 107
View file @ 47d5633b
[epydoc] # Epydoc section marker (required by ConfigParser)
# modules
# The list of objects to document. Objects can be named using
# dotted names, module filenames, or package directory names.
# Aliases for this option include "objects" and "values".
#modules: ../../src/Modules, ../../src/*.py
modules: ../../src/Modules, ../../src/*.py
#modules: src/Modules/Db.py, src/Modules/File.py, src/Modules/Config.py
# output
# The type of output that should be generated. Should be one
# of: html, text, latex, dvi, ps, pdf.
output: pdf
# target
# The path to the output directory. May be relative or absolute.
target: doc/API/api
# docformat
# The default markup language for docstrings, for modules that do
# not define __docformat__. Defaults to epytext.
docformat: epytext
# css
# The CSS stylesheet for HTML output. Can be the name of a builtin
# stylesheet, or the name of a file.
#css: white
# name
# The documented project's name.
name: "Mutalyzer 2.0"
# url
# The documented project's URL.
url: http://www.mutalyzer.nl/2.0/
# link
# HTML code for the project link in the navigation bar. If left
# unspecified, the project link will be generated based on the
# project's name and URL.
#link: <a href="somewhere">My Cool Project</a>
# top
# The "top" page for the documentation. Can be a URL, the name
# of a module or class, or one of the special names "trees.html",
# "indices.html", or "help.html"
top: ../../src
# help
# An alternative help file. The named file should contain the
# body of an HTML file; navigation bars will be added to it.
#help: my_helpfile.html
# frames
# Whether or not to include a frames-based table of contents.
#frames: yes
# private
# Whether or not to inclue private variables. (Even if included,
# private variables will be hidden by default.)
private: yes
# imports
# Whether or not to list each module's imports.
imports: no
# verbosity
# An integer indicating how verbose epydoc should be. The default
# value is 0; negative values will supress warnings and errors;
# positive values will give more verbose output.
verbosity: 1
# parse
# Whether or not parsing should be used to examine objects.
parse: yes
# introspect
# Whether or not introspection should be used to examine objects.
introspect: yes
# graph
# The list of graph types that should be automatically included
# in the output. Graphs are generated using the Graphviz "dot"
# executable. Graph types include: "classtree", "callgraph",
# "umlclass". Use "all" to include all graph types
graph: all
# dotpath
# The path to the Graphviz "dot" executable, used to generate
# graphs.
dotpath: /usr/bin/dot
# sourcecode
# Whether or not to include syntax highlighted source code in
# the output (HTML only).
#sourcecode: yes
# pstat
# The name of one or more pstat files (generated by the profile
# or hotshot module). These are used to generate call graphs.
#pstat: profile.out
# separate-classes
# Whether each class should be listed in its own section when
# generating LaTeX or PDF output.
separate-classes: yes
doc/API/mkapidoc.sh deleted 100644 → 0
+ 0
− 5
View file @ 47d5633b
#!/bin/sh
epydoc --config api.conf
mv api/api.pdf .
rm -rf api/
doc/Makefile 0 → 100644
+ 177
− 0
View file @ 2f33e62c
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = .build
# 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 http://sphinx-doc.org/)
endif
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " xml to make Docutils-native XML files"
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
clean:
rm -rf $(BUILDDIR)/*
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Mutalyzer.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Mutalyzer.qhc"
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/Mutalyzer"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Mutalyzer"
@echo "# devhelp"
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
latexpdfja:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through platex and dvipdfmx..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
man:
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
texinfo:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
info:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
gettext:
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
xml:
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
@echo
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
pseudoxml:
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
@echo
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
doc/TechnicalReference/TechnicalReference.tex
+ 78
− 70
View file @ 2f33e62c
This diff is collapsed.
doc/admin.rst 0 → 100644
+ 150
− 0
View file @ 2f33e62c
.. highlight:: none
.. _admin:
Administration
==============
For administrative tasks, Mutalyzer comes with the ``mutalyzer-admin`` command
line utility. Use its ``-h`` argument in combination with any subcommand for
detailed usage information, for example::
$ mutalyzer-admin setup-database -h
usage: mutalyzer-admin setup-database [-h] [--destructive] [-c ALEMBIC_CONFIG]
Setup database tables (if they do not yet exist).
optional arguments:
-h, --help show this help message and exit
--destructive delete any existing tables and data
-c ALEMBIC_CONFIG, --alembic-config ALEMBIC_CONFIG
path to Alembic configuration file
If Alembic config is given (--alembic-config), this also prepares the database
for future migrations with Alembic (recommended).
Managing genome assemblies
--------------------------
Mutalyzer can be loaded with any number of genome assemblies. Each assembly
includes a list of chromosomes. To list the currently loaded genome
assemblies::
$ mutalyzer-admin assemblies list
GRCh37 (hg19), Homo sapiens (9606)
GRCm38 (mm10), Mus musculus (10090)
Loading a new genome assembly is done with information in a JSON file, of
which there are some examples in the Mutalyzer source tree under the
``extras/assemblies`` directory, for example::
$ mutalyzer-admin assemblies add extras/assemblies/GRCh37.json
For any genome assembly, transcript mappings can be imported. These include
genomic coordinate mappings of their CDS and exons. Currently, three sources
of transcript mappings are supported.
.. note:: The following ``mutalyzer-admin assemblies`` subcommands all accept
an optional ``--assembly`` argument to specify the genome assembly
to import to.
Import mappings from an NCBI mapview file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The NCBI provides FTP downloads of transcript mappings for a large number of
genome assemblies as used by their `Map Viewer
<http://www.ncbi.nlm.nih.gov/mapview/>`_ service. These can be imported with
``mutalyzer-admin``, but only after sorting by the *feature_id* and
*chromosome* columns.
For example, to import transcript mappings for the GRCh37 assembly, run the
following::
$ wget ftp://ftp.ncbi.nih.gov/genomes/H_sapiens/ARCHIVE/BUILD.37.2/mapview/seq_gene.md.gz
$ zcat seq_gene.md.gz | sort -k 11,11 -k 2,2 > seq_gene.sorted.md
$ mutalyzer-admin assemblies import-mapview seq_gene.sorted.md 'GRCh37.p2-Primary Assembly'
.. note:: The last argument, ``GRCh37.p2-Primary Assembly``, defines the group
label to filter the file on. You would usually want to include it.
Import mappings from the UCSC Genome Browser MySQL database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Transcript mappings from the `UCSC Genome Browser MySQL database
<https://genome.ucsc.edu/goldenPath/help/mysql.html>`_ can be imported on a
per-gene basis. This is useful when the NCBI mappings do not (yet) include a
certain gene or transcript.
For example, to import all TTN transcript mappings::
$ mutalyzer-admin assemblies import-gene
.. note:: This subcommand chooses the UCSC genome assembly by using the alias
of the specified Mutalyzer genome assembly (`hg19` by default).
Import mappings from a reference file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For transcript mappings that are not available from our usual sources,
importing from a genomic reference is supported::
$ mutalyzer-admin assemblies import-reference NC_012920.1
.. note:: Currently this subcommand is restricted to importing mtDNA
transcripts, since it has the chromosome hard coded and only
supports one exon per transcript.
Showing announcements to users
------------------------------
It is possible to define an announcement to be shown on the website
interface. For example, to display *Hello World!* with a link to the `GNU
Hello World! <http://www.gnu.org/fun/jokes/helloworld.html>`_ page::
$ mutalyzer-admin announcement set 'Hello World!' \
--url http://www.gnu.org/fun/jokes/helloworld.html
To remove the announcement, use ``unset``::
$ mutalyzer-admin announcement unset
Synchronizing the cache with other installations
------------------------------------------------
Using the ``sync-cache`` subcommand, the reference file cache of a remote
Mutalyzer installation can be queried for new entries which are then retrieved
and added to the local cache.
The primary purpose for this is synchronizing reference files loaded by users
with the reference file loader between different servers. These reference
files are assigned a unique accession number (starting with ``UD_``) upon
creation, which is at that point unknown to any other Mutalyzer server.
For example, to synchronize the local reference file cache with the `primary
Mutalyzer server <https://mutalyzer.nl/>`_::
$ mutalyzer-admin sync-cache 'https://mutalyzer.nl/services/?wsdl' \
'https://mutalyzer.nl/Reference/{file}'
Mutalyzer database setup
------------------------
After installation, a database needs to be setup for Mutalyzer to run (see
:ref:`install-setup`)::
$ mutalyzer-admin setup-database --alembic-config migrations/alembic.ini
The ``--alembic-config`` argument points to the ``alembic.ini`` file in the
Mutalyzer source tree and it enables initialization of database migration
management. It is recommended to include it, but you don't need it if you
don't plan to ever upgrade your Mutalyzer installation.
This subcommand also takes an optional ``--destructive`` argument, which can
be used to remove any existing database content.
doc/api.rst 0 → 100644
+ 283
− 0
View file @ 2f33e62c
API reference
=============
.. note:: This reference is incomplete. In particular, modules without
reStructuredText formatted docstrings are omitted.
.. mutalyzer
---------
.. automodule:: mutalyzer
:members: NOMENCLATURE_VERSION_INFO, NOMENCLATURE_VERSION, COPYRIGHT_YEARS, SOAP_NAMESPACE
mutalyzer.announce
------------------
.. automodule:: mutalyzer.announce
:members:
mutalyzer.config
----------------
.. automodule:: mutalyzer.config
:members:
.. mutalyzer.config.default_settings
---------------------------------
.. automodule:: mutalyzer.config.default_settings
:members:
.. mutalyzer.Crossmap
------------------
.. automodule:: mutalyzer.Crossmap
:members:
mutalyzer.db
------------
.. automodule:: mutalyzer.db
:members:
mutalyzer.db.models
-------------------
.. I have no idea why, but somehow :members: includes `or_` and `relationship`
from SQLAlchemy (which are imported in the module).
.. automodule:: mutalyzer.db.models
:members:
:exclude-members: or_, relationship
mutalyzer.db.queries
--------------------
.. automodule:: mutalyzer.db.queries
:members:
:exclude-members: and_, or_
.. mutalyzer.describe
------------------
.. automodule:: mutalyzer.describe
:members:
.. mutalyzer.entrypoints
---------------------
.. automodule:: mutalyzer.entrypoints
:members:
mutalyzer.entrypoints.admin
---------------------------
.. automodule:: mutalyzer.entrypoints.admin
:members:
mutalyzer.entrypoints.batch_processor
-------------------------------------
.. automodule:: mutalyzer.entrypoints.batch_processor
:members:
mutalyzer.entrypoints.mutalyzer
-------------------------------
.. automodule:: mutalyzer.entrypoints.mutalyzer
:members:
mutalyzer.entrypoints.service_json
----------------------------------
.. automodule:: mutalyzer.entrypoints.service_json
:members:
mutalyzer.entrypoints.service_soap
----------------------------------
.. automodule:: mutalyzer.entrypoints.service_soap
:members:
mutalyzer.entrypoints.website
-----------------------------
.. automodule:: mutalyzer.entrypoints.website
:members:
.. mutalyzer.File
--------------
.. automodule:: mutalyzer.File
:members:
.. mutalyzer.GenRecord
-------------------
.. automodule:: mutalyzer.GenRecord
:members:
.. mutalyzer.grammar
-----------------
.. automodule:: mutalyzer.grammar
:members:
.. mutalyzer.mapping
-----------------
.. automodule:: mutalyzer.mapping
:members:
.. mutalyzer.models
----------------
.. automodule:: mutalyzer.models
:members:
.. mutalyzer.mutator
-----------------
.. automodule:: mutalyzer.mutator
:members:
.. mutalyzer.output
----------------
.. automodule:: mutalyzer.output
:members:
.. mutalyzer.parsers
-----------------
.. automodule:: mutalyzer.parsers
:members:
.. mutalyzer.parsers.genbank
-------------------------
.. automodule:: mutalyzer.parsers.genbank
:members:
.. mutalyzer.parsers.lrg
---------------------
.. automodule:: mutalyzer.parsers.lrg
:members:
mutalyzer.redisclient
---------------------
.. automodule:: mutalyzer.redisclient
:members:
.. mutalyzer.Retriever
-------------------
.. automodule:: mutalyzer.Retriever
:members:
.. mutalyzer.Scheduler
-------------------
.. automodule:: mutalyzer.Scheduler
:members:
.. mutalyzer.services
------------------
.. automodule:: mutalyzer.services
:members:
mutalyzer.services.json
-----------------------
.. automodule:: mutalyzer.services.json
:members:
.. mutalyzer.services.rpc
----------------------
.. automodule:: mutalyzer.services.rpc
:members:
mutalyzer.services.soap
-----------------------
.. automodule:: mutalyzer.services.soap
:members:
mutalyzer.stats
---------------
.. automodule:: mutalyzer.stats
:members:
mutalyzer.sync
--------------
.. automodule:: mutalyzer.sync
:members:
.. mutalyzer.util
--------------
.. automodule:: mutalyzer.util
:members:
.. mutalyzer.variantchecker
------------------------
.. automodule:: mutalyzer.variantchecker
:members:
mutalyzer.website
-----------------
.. automodule:: mutalyzer.website
:members:
mutalyzer.website.views
-----------------------
.. automodule:: mutalyzer.website.views
:members:
doc/changelog.rst 0 → 100644
+ 1
− 0
View file @ 2f33e62c
.. include:: ../CHANGES.rst
doc/conf.py 0 → 100644
+ 275
− 0
View file @ 2f33e62c
# -*- coding: utf-8 -*-
#
# Mutalyzer documentation build configuration file, created by
# sphinx-quickstart on Mon Feb 17 11:01:56 2014.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# 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.abspath('..'))
# -- General configuration ------------------------------------------------
import mutalyzer
# 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.todo',
'sphinx.ext.viewcode',
]
# Include todo directives.
todo_include_todos = False
# Add any paths that contain templates here, relative to this directory.
templates_path = ['.templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'Mutalyzer'
copyright = u'%s, %s' % ('%d-%d' % mutalyzer.COPYRIGHT_YEARS, mutalyzer.__author__)
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = '.'.join(mutalyzer.__version__.split('.')[:2])
# The full version, including alpha/beta/rc tags.
release = mutalyzer.__version__
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['.build']
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'default'
# on_rtd is whether we are on readthedocs.org
on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
if not on_rtd: # only import and set the theme if we're building docs locally
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['.static']
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'Mutalyzerdoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
('index', 'Mutalyzer.tex', u'Mutalyzer Documentation',
u'Leiden University Medical Center', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'mutalyzer', u'Mutalyzer Documentation',
[u'Leiden University Medical Center'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'Mutalyzer', u'Mutalyzer Documentation',
u'Leiden University Medical Center', 'Mutalyzer',
'HGVS variant nomenclature checker.', 'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False
doc/config.rst 0 → 100644
+ 92
− 0
View file @ 2f33e62c
.. highlight:: none
.. _config:
Configuration
=============
This section describes how to configure Mutalyzer and includes a list of all
available configuration settings.
Mutalyzer looks for its configuration in the file specified by the
``MUTALYZER_SETTINGS`` environment variable. Make sure to always have this
environment variable set when invoking any component of Mutalyzer. One way of
doing this is by exporting it::
$ export MUTALYZER_SETTINGS=~/mutalyzer/settings.py
If you like, you can add this command to your ``~/.bashrc`` to have it
executed every time you open a shell.
Another way is by prefixing your invocations with
``MUTALYZER_SETTINGS=...``. For example::
$ MUTALYZER_SETTINGS=~/mutalyzer/settings.py mutalyzer-website
Example configuration
---------------------
If you followed the steps in :ref:`install`, this is a standard configuration
file that will work for you:
.. code-block:: python
REDIS_URI = 'redis://localhost'
DATABASE_URI = 'postgresql://mutalyzer:*****@localhost/mutalyzer'
This is not yet a minimal configuration. In fact, you can run Mutalyzer
without a configuration file since the default configuration works out of the
box. The default configuration uses a mock Redis instance, an in-memory
database backend and a temporary directory for cache and log files, so it is
not recommended for anything more than playing around.
The next section describes all available configuration settings.
Configuration settings
----------------------
.. note:: Todo: This section is incomplete.
Note that the configuration file is interpreted as a Python module, so you can
use arbitrary Python expressions as configuration values, or even import other
modules in it.
Unsetting a configuration setting is done by using the value `None`. If no
default value is mentioned for any configuration setting below it means it is
not set by default.
Database settings
^^^^^^^^^^^^^^^^^
DATABASE_URI
SQLAlchemy database connection URI specifying the database used to store
users, samples, variants, etcetera.
================ =====================================================
Database system Example URI
================ =====================================================
PostgreSQL ``postgresql://mutalyzer:*****@localhost/mutalyzer``
MySQL ``mysql://mutalyzer:*****@localhost/mutalyzer``
SQLite ``sqlite:////tmp/mutalyzer.db``
================ =====================================================
See the SQLAlchemy documentation on
`Engine Configuration
<http://docs.sqlalchemy.org/en/latest/core/engines.html>`_ for more
information.
`Default value:` ``sqlite://`` (in-memory SQLite database)
Miscellaneous settings
^^^^^^^^^^^^^^^^^^^^^^
TESTING
If set to `True`, Mutalyzer assumes to be running its unit tests. This is
done automatically in the provided test suite, so you should never have to
change this setting.
`Default value:` `False`
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment