Difference between revisions of "Contribute code"

From Archivematica
Jump to navigation Jump to search
(Link to contributing.md)
(→‎Patches: Move contents of pull requests page to section)
Line 4: Line 4:
  
 
==Patches==
 
==Patches==
If you find a bug in this project or would like to make an enhancement, please be encouraged to contribute a patch by following [[Pull requests|these instructions]].
+
 
 +
If you find a bug in this project or would like to make an enhancement, please be encouraged to contribute code via a pull request.  Archivematica code is available on github. We will accept git pull requests from individuals who have submitted a [[Contributor Agreement]].
 +
 
 +
For more information please visit:
 +
* https://help.github.com/articles/creating-a-pull-request
 +
* https://help.github.com/articles/using-pull-requests
 +
* https://help.github.com/articles/fork-a-repo
  
 
==Commit access==
 
==Commit access==

Revision as of 12:42, 23 March 2017

Main Page > Development > Contribute code

Expanded contribution guidelines can also be found in the Archivematica contributing document.

Patches

If you find a bug in this project or would like to make an enhancement, please be encouraged to contribute code via a pull request. Archivematica code is available on github. We will accept git pull requests from individuals who have submitted a Contributor Agreement.

For more information please visit:

Commit access

Anyone can contribute code patches to this project. Project collaborators and regular patch contributors will be given access to commit directly to the git code repository.

Contributor's Agreement

In order to accept any patches or code commits, contributors must first sign the Archivematica Contributor's Agreement.

Standards

Code Style Guide For Archivematica

Archivematica follows common Python coding standards, linked below. We encourage installing a Python linter to help with this. flake8 is recommended because it wraps three common linters (pep8, pyflakes, mccabe).

  • PEP8 for styling
    • Exception is line length, which should be wrapped at 79 characters or left long for the IDE to wrap.
    • Imports are sorted alphabetically within their grouping to reduce duplicate imports
  • PEP257 for docstring structure
    • Parameters and return values should be specified in Sphinx-style.
  • See also this pull request and associated discussion.

Example docstrings with Sphinx markup below. Other attributes that can be used in a docstring can be found on the Sphinx website.

def get_unit_status(unit_uuid, unit_type):
    """
    Get status for a SIP or Transfer.

    Returns a dict with status info.  Keys will always include 'status' and
    'microservice', and may include 'sip_uuid'.

    Status is one of FAILED, REJECTED, USER_INPUT, COMPLETE or PROCESSING.
    Microservice is the name of the current microservice.
    SIP UUID is populated only if the unit_type was unitTransfer and status is
    COMPLETE.  Otherwise, it is None.

    :param str unit_uuid: UUID of the SIP or Transfer
    :param str unit_type: unitSIP or unitTransfer
    :return: Dict with status info.
    """
def each_child(path, file_group_identifier, base_path, base_path_name, sip_uuid):
    """
    Iterates over entries in a filesystem, beginning at `path`.

    At each entry in the filesystem, yields either a File model instance
    (for files) or a string (for directories).

    When iterating, makes two passes: first iterating over files, then
    directories. Does not iterate over directories; consumers should
    call this function again on directory strings to recurse.

    :param string path: path to a directory on disk to recurse into.
    :raises ValueError: if the specified path does not exist, or is not a directory.
    """

File Structure

The file structure in Archivematica will comply with the Filesystem Hierarchy Standard (FHS).
More information on this standard is available at:
http://www.pathname.com/fhs/