├── .gitignore ├── CODESTYLE.rst ├── CONTRIBUTING.md ├── GITFLOW.rst ├── README.rst ├── RST_DOC_STYLE.rst └── contrib └── candidates-sort.py /.gitignore: -------------------------------------------------------------------------------- 1 | wiki 2 | issues 3 | -------------------------------------------------------------------------------- /CODESTYLE.rst: -------------------------------------------------------------------------------- 1 | Code style requirements for TurnKey Linux 2 | ========================================= 3 | 4 | This doc is a placeholder for our WIP code style requirements. 5 | 6 | Until we have a document of substance, this will be maintained as a `GH wiki 7 | page`_. 8 | 9 | .. _GH wiki page: https://github.com/turnkeylinux/tracker/wiki/Code-styling 10 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to TurnKey 2 | 3 | The following is a consolidated series of guidelines for contributions to TurnKey Linux (TKL). These guidelines are derived from a number of existing documents that are currently spread across GitHub and the [documentation](https://www.turnkeylinux.org/docs) section of the TKL website. If you feel that these guidelines are lacking, feel free to make changes as you see fit. 4 | 5 | 6 | ## Contents 7 | 8 | [General Information](#general-information) 9 | * [About TurnKey Linux](#about-turnkey-linux) 10 | * [Development Toolchain](#development-toolchain) 11 | 12 | [Contributing](#contributing) 13 | * [GitFlow](#gitflow) 14 | * [Contribution Walkthrough](#contribution-walkthrough) 15 | * [Bug reports and feature requests](#bug-reports-and-feature-requests) 16 | 17 | ## General Information 18 | 19 | ### About TurnKey Linux 20 | 21 | TurnKey GNU/Linux is an open source library of Debian based system images packaged as virtual appliances. Virtual appliances function as self contained systems that are capable of running on industry standard hardware or virtual machines created through software such as Virtualbox. Consult [this guide](https://www.turnkeylinux.org/docs/installation-appliances-virtualbox-new) for a basic overview on how to install virtual appliances. 22 | 23 | All TKL source code is managed by [Git](https://git-scm.com/documentation) and hosted here on GitHub under either: 24 | * [turnkeylinux](https://github.com/turnkeylinux) for TurnKey related components and projects. 25 | * [turnkeylinux-apps](https://github.com/turnkeylinux-apps) for TurnKey appliances. 26 | 27 | Developers with good ideas are encouraged to be bold and contribute code. 28 | 29 | ### Development Toolchain 30 | 31 | * [TKLDev](https://www.turnkeylinux.org/tkldev): This is the recommended tool for appliance development. As "the mother of all TurnKey apps", TKLDev is a self contained appliance that is capable of rapidly prototyping new Linux distributions and building existing integrations from source material. For more detailed information on using this appliance, consult the docs in the [TKLDev repository](https://github.com/turnkeylinux-apps/tkldev/tree/master/docs) here on GitHub. 32 | * [TKLPatch](https://www.turnkeylinux.org/docs/tklpatch): A set of shell scripts that may be used to customize and extend existing virtual appliances. While recent versions of TKLDev enable the creation of appliances from source, TKLPatch may still be used for light customization. 33 | 34 | ## Contributing 35 | 36 | ### Gitflow 37 | 38 | Development of TKL is loosely based on [GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html), a widely accepted set of guidelines for contributing to projects over GitHub. As such, TKL development follows these basic guidelines: 39 | * Anything in the master branch is deployable (builds that have successfully been proven to work). 40 | * When working on something new (ie: a bugfix or a new feature), create a descriptively named branch off of the master. Each new branch should address a single issue. 41 | * Commit to that branch locally and regularly. Source code should be documented and rationale for changes included in commits. 42 | * Open a pull request for help, feedback or branch merging. 43 | * Once someone else has reviewed and signed off on the changes, the project maintainer or a core developer will merge it with the official repository. 44 | * Once it is merged and pushed to the master, the project should be rebuilt and released immediately. 45 | 46 | Collaboration is facilitated over GitHub through the use of [fork](https://help.github.com/articles/fork-a-repo/) and [pull requests](https://help.github.com/articles/using-pull-requests/). In order to make use of these features, developers will need to [create a GitHub account]() and add their SSH public key if they have not already done so. 47 | 48 | ### Contribution Walkthrough 49 | 50 | **Fork and clone source:** 51 | * To begin, login and find a repository that you would like to work on. 52 | * Within the desired repository, press the ``fork`` button to fork the repository. 53 | * The repository will then need to be cloned before you can work on it. You can do so with this snippet of code: 54 | 55 | `git clone git@github.com:USERNAME/PROJECTNAME.git` 56 | 57 | * Once the repository has been cloned, it will have a ``remote`` called ``origin``. This will point to your newly created fork on GitHub rather than the original repository. 58 | * You will need to add another ``remote`` in order to keep track of the original repository. In this example, it will be called ``upstream``: 59 | 60 | ``` 61 | cd PROJECTNAME 62 | git remote add upstream https://github.com/ORGANIZATION/PROJECTNAME.git 63 | # Fetch any new changes to the original repository 64 | git fetch upstream 65 | # Merge any changes fetched into your working branch 66 | git merge upstream/master 67 | ``` 68 | 69 | **Make your changes:** 70 | 71 | * Create a branch with a descriptive name related to your changes. Note that you are limited to one ``pull request`` per branch. 72 | 73 | `git checkout -b DESCRIPTIVE_BRANCH_NAME` 74 | 75 | * Make your changes, testing and committing as you progress. Remember to only address one issue per branch / pull request. 76 | * Perform final testing before pushing any changes. 77 | 78 | **Push changes and submit a pull request:** 79 | 80 | Now that you're finished and all changes are committed, you need to push them to your GitHub repository: 81 | 82 | git push origin DESCRIPTIVE_BRANCH_NAME 83 | 84 | Finally, submit a ``pull request`` so that the maintainer or a core developer may review your changes and provide necessary feedback. Further commits pushed into the same branch will be automatically included in your ``pull request`` until it is closed. Upon successfull review your changes will be merged into the official repository. 85 | 86 | ### Bug Reports and feature requests 87 | 88 | TKL uses GitHub's project management features to track development. Included in these features are the [issue tracker](https://github.com/turnkeylinux/tracker/issues/) (used to report bugs and record feature requests) and the [Wiki](https://github.com/turnkeylinux/tracker/wiki) (used to propose and track appliance candidates and as a general purpose whiteboard for TKL development). 89 | 90 | Before opening a new issue, please check to see if a similar bug, issue or feature request already exists in the tracker. If a similar topic is currently open, post a comment stating that it also affects you. Knowing an issue affects multiple users is useful when we decide how to prioritize limited development resources. Please try and include any additional information you think might help us close the issue. 91 | 92 | The ideal bug / issue report includes: 93 | * A detailed description of the bug / issue. 94 | * Step by step instructions on how it may be reproduced. 95 | * The output that is generated from using the ``turnkey-version`` command, which should look like this: 96 | ``` 97 | turnkey-appliance_name-major_version.minor_version-debian_codename-architecture 98 | ``` 99 | 100 | The ideal feature request includes: 101 | * A detailed description of the feature and the component it relates to. 102 | * One or more cases in which the feature might be of use. 103 | * Any other relevant information. 104 | 105 | Note that the tracker is not intended to be used as a forum for support or general discussion. For technical support or general discussion, please use the appropriate [forum](https://www.turnkeylinux.org/forum). 106 | -------------------------------------------------------------------------------- /GITFLOW.rst: -------------------------------------------------------------------------------- 1 | Recommended Git Flow 2 | ==================== 3 | 4 | All TurnKey source code is managed by `git`_, and hosted on 5 | `GitHub`_ in one of the following organizations: 6 | 7 | * `turnkeylinux`_: TurnKey related components and projects. 8 | * `turnkeylinux-apps`_: TurnKey appliances. 9 | 10 | Not only is `GitHub`_ used to host the source code, but also to 11 | facilitate collaboration via `forks`_ and `pull requests`_. 12 | 13 | There are infinate ways to develop with git, but when teams and 14 | collaborators are involved it's recommended to follow some sort of flow 15 | and guidelines. The most widely acceptable flows are `git-flow`_ and 16 | `GitHub flow`_. 17 | 18 | Guidelines 19 | ---------- 20 | 21 | TurnKey related development is loosly based on the GitHub flow, and 22 | follows these guidelines: 23 | 24 | * Anything in the master branch is deployable - builds successfully and 25 | is tested to work. 26 | * When working on something new, whether it be a bugfix or new feature, 27 | create a descriptively named branch off of master. Each new branch 28 | should address just one issue (i.e. create a separate branch from 29 | master for each issue). 30 | * Commit to that branch locally and regularly. Source code should be 31 | documented and rationale for changes included in commits. 32 | * When you need feedback or help, or you think the branch is ready for 33 | merging, open a pull request. 34 | * After someone else has reviewed and signed off on the changes, the 35 | project maintainer or a core developer will perform the merge in the 36 | official repository. 37 | * Once it is merged and pushed to master, the project should be rebuilt 38 | and released immediately. 39 | 40 | Walk through 41 | ------------ 42 | 43 | As described above, GitHub is used to facilitate collaboration, so the 44 | first thing to do is create a `GitHub account`_ and add your SSH public 45 | key if you haven't already done so. 46 | 47 | Fork and clone the source 48 | ''''''''''''''''''''''''' 49 | 50 | Next, fork the project you want to hack on: 51 | 52 | * Log into `GitHub`_, and browse to the projects repository. 53 | * Click the ``fork`` button. 54 | 55 | That's it. You've successfully forked the project repository, but so far 56 | it only exists on GitHub. 57 | 58 | To be able to work on the project you'll need to clone it:: 59 | 60 | git clone git@github.com:USERNAME/PROJECTNAME.git 61 | 62 | So far so good. When a repository is cloned, it has a default ``remote`` 63 | called ``origin`` that points to your fork on GitHub, not the original 64 | repository it was forked from. 65 | 66 | To keep track of the original repository, you need to add another 67 | remote, we'll call it ``upstream``:: 68 | 69 | cd PROJECTNAME 70 | git remote add upstream https://github.com/ORGANIZATION/PROJECTNAME.git 71 | 72 | # Fetch any new changes to the original repository 73 | git fetch upstream 74 | 75 | # Merge any changes fetched into your working branch 76 | git merge upstream/master 77 | 78 | Make your changes 79 | ''''''''''''''''' 80 | 81 | * **Create a branch**: Remember to branch off master/main. Note: you have only one ``pull request`` per branch:: 82 | 83 | git checkout -b DESCRIPTIVE_BRANCH_NAME 84 | 85 | * **Hack away**: Make your changes. Note: please only address one issue per branch/pull request. 86 | * **Test**: Test as you go. 87 | * **Commit**: Commit as you go, provide a biref descrption:: 88 | 89 | git add FILENAME.EXT 90 | git commit -m "BRIEF DESCRIPTION" 91 | 92 | * **Test**: Perform final testing. 93 | 94 | Push changes and submit a Pull Request 95 | '''''''''''''''''''''''''''''''''''''' 96 | 97 | Now that you're finished hacking and all changes are committed, you need 98 | to push them to your GitHub repository:: 99 | 100 | git push origin DESCRIPTIVE_BRANCH_NAME 101 | 102 | Last thing to do is send a ``pull request`` so the maintainer or one of 103 | the core developers can review, sign off, and perform the merge in the 104 | official repository. 105 | 106 | * Browse to https://github.com/USERNAME/PROJECTNAME/tree/DESCRIPTIVE_BRANCH_NAME 107 | * Click ``Pull Request``, describe the change and click ``Send pull request``. 108 | 109 | Hooray! You did it. 110 | 111 | If for some reason the maintainer or one of the core developers has a 112 | problem with your change, they won't want to merge until fixed. 113 | 114 | The good news is that whenever you commit and push more changes to that 115 | branch of your code, they will be included in that original pull request 116 | until it is closed. 117 | 118 | 119 | .. _git: http://git-scm.com/documentation 120 | .. _GitHub: https://github.com 121 | .. _turnkeylinux: https://github.com/turnkeylinux 122 | .. _turnkeylinux-apps: https://github.com/turnkeylinux-apps 123 | .. _forks: https://help.github.com/articles/fork-a-repo 124 | .. _pull requests: https://help.github.com/articles/using-pull-requests 125 | .. _git-flow: http://nvie.com/posts/a-successful-git-branching-model 126 | .. _GitHub flow: http://scottchacon.com/2011/08/31/github-flow.html 127 | .. _GitHub account: https://github.com/signup 128 | -------------------------------------------------------------------------------- /README.rst: -------------------------------------------------------------------------------- 1 | =================== 2 | TurnKey Dev Tracker 3 | =================== 4 | 5 | TurnKey uses GitHub's project management features to track development. 6 | 7 | Resources: 8 | 9 | 1) `Issue Tracker`_: used to report and track bugs, issues and 10 | feature requests related to TurnKey Linux. 11 | 12 | 2) `Wiki`_: used to propose and track appliance candidates, 13 | and also as a general purpose whiteboard for TurnKey development. 14 | 15 | This tracker is **NOT** intended to be used as: 16 | 17 | * A `support forum`_ we already have one of those. 18 | * A `general discussion forum`_, we have one of those as well. 19 | 20 | Reporting a bug, issue or feature request 21 | ----------------------------------------- 22 | 23 | The ideal bug/issue includes: 24 | 25 | 1) A detailed description of the issue. 26 | 2) How to reproduce the issue step by step. 27 | 3) Any extra information that might be relevant, such as appliance 28 | name, version, deployment (ISO, OpenStack, Amazon EC2), any 29 | changes made prior to issue, etc. 30 | 31 | The ideal feature request includes: 32 | 33 | 1) A detailed description of feature and component it relates to. 34 | 2) One or more use cases for the feature. 35 | 3) Any extra information that might be relevant. 36 | 37 | Before creating a new issue on the `Issue Tracker`_, please check to see if a similar issue 38 | already exists. If it does, post a comment showing it also affects you. 39 | Knowing an issue effects multiple users is useful when we decide how 40 | to prioritize limited development resources. Please try and include any additional 41 | information you think might help us close the issue. 42 | 43 | Contributing as a developer 44 | --------------------------- 45 | 46 | TurnKey is 100% open source and the code for all components is right here on GitHub. 47 | Developers with good ideas are strongly encouraged to be bold and contribute code. Use the source Luke! 48 | 49 | See the `guidelines and walk through`_. 50 | 51 | .. _Issue Tracker: https://github.com/turnkeylinux/tracker/issues/ 52 | .. _Wiki: https://github.com/turnkeylinux/tracker/wiki/ 53 | .. _support forum: http://www.turnkeylinux.org/forum/support/ 54 | .. _general discussion forum: http://www.turnkeylinux.org/forum/general/ 55 | .. _guidelines and walk through: https://github.com/turnkeylinux/tracker/blob/master/GITFLOW.rst 56 | 57 | -------------------------------------------------------------------------------- /RST_DOC_STYLE.rst: -------------------------------------------------------------------------------- 1 | Recommended RST Document Style 2 | ============================== 3 | 4 | This document is basically a cheat sheet for reStructuredText to help guide new people in following TurnKeyLinux's documenting style in GitHub. 5 | 6 | Contents 7 | -------- 8 | 9 | * `Headers <#Headers>`_ 10 | 11 | * `Horizontal Rules <#horizontal-rules>`_ 12 | 13 | * `Code Formatting <#code-formatting>`_ 14 | 15 | * `Basic Formatting <#basic-formatting>`_ 16 | 17 | * `Code Blocks <#code-blocks>`_ 18 | 19 | * `Escaping Markup <#escaping-markup>`_ 20 | 21 | * `Lists <#Lists>`_ 22 | 23 | * `Linking <#linking>`_ 24 | 25 | * `References <#references>`_ 26 | 27 | Headers 28 | ------- 29 | 30 | Typically ``Header 1`` is used for README.rst, any additional documentation pages will start with ``Header 2``, then ``Header 3`` for page sections and ``Header 4`` for subsections. ``Header 5`` is rarely used. 31 | 32 | The underlining *must* be as long as the header text. 33 | 34 | Example of headers:: 35 | 36 | ======== 37 | Header 1 38 | ======== 39 | 40 | Header 2 41 | ======== 42 | 43 | Header 3 44 | -------- 45 | 46 | Header 3 with a longer text 47 | --------------------------- 48 | 49 | Header 4 50 | ^^^^^^^^ 51 | 52 | Header 5 53 | """""""" 54 | 55 | Horizontal Rules 56 | ---------------- 57 | 58 | Simply place four or more hyphens (``-``) on there own line with blank lines before and after, with no indent 59 | 60 | For example: 61 | 62 | ``----`` 63 | 64 | ---- 65 | 66 | Code Formatting 67 | --------------- 68 | 69 | To use ``highlighted monospaced text``, prepend and append the text with a double backquote (``````). 70 | 71 | For example:: 72 | 73 | Change into directory with ``cd /etc/`` and show a long list of of the directory with ``ls -l``. 74 | 75 | Change into directory with ``cd /etc/`` and show a long list of of the directory with ``ls -l``. 76 | 77 | Basic Formatting 78 | ---------------- 79 | 80 | ``*italic text*`` 81 | 82 | *italic text* 83 | 84 | ``**bold text**`` 85 | 86 | **bold text** 87 | 88 | Code Blocks 89 | ----------- 90 | 91 | Follow a sentence or paragraph with a double colon (``::``), then leave a blank line and indent the next line 1 tab or four spaces to create a monospaced highlighted block of text. 92 | 93 | For example:: 94 | 95 | the quick brown fox jumps over the lazy dog:: 96 | 97 | the quick brown fox jumps over the lazy dog 98 | the quick brown fox jumps over the lazy dog 99 | 100 | the quick brown fox jumps over the lazy dog:: 101 | 102 | the quick brown fox jumps over the lazy dog 103 | the quick brown fox jumps over the lazy dog 104 | 105 | Escaping Markup 106 | --------------- 107 | 108 | Occassionally you will want to use markup characters just as them themselves and without being interpreted. Markup characters are not interpreted when used within double backquotes or within a code block. In other contexts, you can precede the markup character with a backslash (\\) to escape the interpretation. This also applies to the backslash itself. 109 | 110 | For example: 111 | 112 | ``\*This\* is not *italic* and \**this\** is not **bold**.`` 113 | 114 | \*This\* is not *italic* and \**this\** is not **bold**. 115 | 116 | Lists 117 | ----- 118 | Numbered 119 | ^^^^^^^^ 120 | 121 | Create a auto-enumerated list with hash and fullstop (``#.``) 122 | 123 | For example:: 124 | 125 | #. First item 126 | #. Second item 127 | #. Third item 128 | 129 | #. Frist sub item 130 | #. Second sub item 131 | #. Fourth item 132 | 133 | #. First item 134 | #. Second item 135 | #. Third item 136 | 137 | #. First sub item 138 | #. Second sub item 139 | #. Fourth item 140 | 141 | Create a numbered list with numbers and a fullstop (``1.``) always starting with ``1`` . 142 | 143 | For example:: 144 | 145 | 1. First item 146 | 2. Second item 147 | 3. Third item 148 | 149 | 1. First sub item 150 | 2. Second sub item 151 | 4. Fourth item 152 | 153 | 1. First item 154 | 2. Second item 155 | 3. Third item 156 | 157 | 1. First sub item 158 | 2. Second sub item 159 | 4. Fourth item 160 | 161 | Bullet 162 | ^^^^^^ 163 | 164 | Create a bullet point list with asterisk (``*``). 165 | 166 | For example:: 167 | 168 | * First item 169 | * Second item 170 | that continues on a second line 171 | * Third item 172 | 173 | * Use nested lists 174 | * By indenting 4-7 spaces 175 | * Fourth item 176 | 177 | * First item 178 | * Second item 179 | that continues on a second line 180 | * Third item 181 | 182 | * Use nested lists 183 | * By indenting 4-7 spaces 184 | * Fourth item 185 | 186 | Linking 187 | ------- 188 | 189 | Hyperlink URLs 190 | ^^^^^^^^^^^^^^ 191 | 192 | Hyperlinks can be created by prepending and appending with a single backqoute (`````) and including the reference or link at the end in angle brackets (``<>``) followed by the underscore (``_``). 193 | 194 | You can also create links that reference a list at the bottom of the page. Using double full stop and a space (``..``) will hide the reference text from being displayed. 195 | 196 | For example:: 197 | 198 | * `Issue Tracker`_ 199 | * `Wiki`_ 200 | * `Support Forum`_ 201 | * `General Discussion Forum`_ 202 | * `Guidelines and Walk Through`_ 203 | 204 | .. _Issue Tracker: https://github.com/turnkeylinux/tracker/issues/ 205 | .. _Wiki: https://github.com/turnkeylinux/tracker/wiki/ 206 | .. _Support Forum: http://www.turnkeylinux.org/forum/support/ 207 | .. _General Discussion Forum: http://www.turnkeylinux.org/forum/general/ 208 | .. _Guidelines and Walk Through: https://github.com/turnkeylinux/tracker/blob/master/GITFLOW.rst 209 | 210 | * `Issue Tracker`_ 211 | * `Wiki`_ 212 | * `Support Forum`_ 213 | * `General Discussion Forum`_ 214 | * `Guidelines and Walk Through`_ 215 | 216 | .. _Issue Tracker: https://github.com/turnkeylinux/tracker/issues/ 217 | .. _Wiki: https://github.com/turnkeylinux/tracker/wiki/ 218 | .. _Support Forum: http://www.turnkeylinux.org/forum/support/ 219 | .. _General Discussion Forum: http://www.turnkeylinux.org/forum/general/ 220 | .. _Guidelines and Walk Through: https://github.com/turnkeylinux/tracker/blob/master/GITFLOW.rst 221 | 222 | Link to Heading 223 | ^^^^^^^^^^^^^^^ 224 | 225 | Link to a heading in the same document. 226 | 227 | ```Code Formatting <#code-formatting>`_`` 228 | 229 | `Code Formatting <#code-formatting>`_ 230 | 231 | Link to File 232 | ^^^^^^^^^^^^ 233 | 234 | Link to a file in the same repo. 235 | 236 | ```Follow TurnKeyLinux Workflow using git and GitHub `_`` 237 | 238 | `Follow TurnKeyLinux Workflow using git and GitHub `_ 239 | 240 | 241 | 242 | References 243 | ---------- 244 | 245 | https://gist.github.com/dupuy/1855764 246 | 247 | https://github.com/ralsina/rst-cheatsheet/blob/master/rst-cheatsheet.rst 248 | 249 | https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html -------------------------------------------------------------------------------- /contrib/candidates-sort.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | # Copyright (c) 2013 Alon Swartz 3 | """Sort TurnKey Linux Appliance Candidates by stupid scoring algorithm""" 4 | 5 | import re 6 | import os 7 | import sys 8 | import getopt 9 | 10 | def fatal(e): 11 | print >> sys.stderr, 'Error: ' + str(e) 12 | sys.exit(1) 13 | 14 | def usage(e=None): 15 | if e: 16 | print >> sys.stderr, 'Error: ' + str(e) 17 | 18 | print >> sys.stderr, 'Syntax: %s path/to/Candidates.md' % sys.argv[0] 19 | print >> sys.stderr, __doc__.strip() 20 | 21 | sys.exit(1) 22 | 23 | class Error(Exception): 24 | pass 25 | 26 | class AttrDict(dict): 27 | """Attribute Dictionary (set and access attributes 'pythonically')""" 28 | def __getattr__(self, name): 29 | if name in self: 30 | return self[name] 31 | raise AttributeError('no such attribute: %s' % name) 32 | 33 | def __setattr__(self, name, val): 34 | self[name] = val 35 | 36 | class Candidate(AttrDict): 37 | def __init__(self): 38 | self.name = None 39 | self.description = None 40 | self.labels = [] 41 | self.supporters = [] 42 | self.resources = [] 43 | 44 | @property 45 | def score(self): 46 | i = 0 47 | if self.description: 48 | i += 1 49 | if len(self.labels) > 0: 50 | i += 1 51 | if 'tklpatch' in self.labels: 52 | i += 1 53 | if len(self.supporters) > 2: 54 | i += 2 55 | if len(self.resources) > 1: 56 | i += 1 57 | 58 | return i 59 | 60 | @property 61 | def title(self): 62 | s = self.name 63 | if self.description: 64 | s += ': %s' % self.description 65 | if self.labels: 66 | s += ' (' + ', '.join(self.labels) + ')' 67 | 68 | return s 69 | 70 | def __str__(self): 71 | s = '### %s\n' % self.title 72 | if self.supporters or self.resources: 73 | s += '\n' 74 | if self.supporters: 75 | s += '* Supporters: %s\n' % ', '.join(self.supporters) 76 | for resource in self.resources: 77 | s += '* %s\n' % resource 78 | 79 | return s 80 | 81 | def parse_candidates(path): 82 | candidates = [] 83 | c = Candidate() 84 | for line in file(path, 'r').readlines(): 85 | line = line.strip() 86 | if not line: 87 | continue 88 | 89 | if line.startswith('###'): 90 | if c.name: 91 | candidates.append(c) 92 | 93 | c = Candidate() 94 | m = re.match('### (.*): (.*) \((.*)\)', line) 95 | if m: 96 | c.name = m.groups()[0].strip() 97 | c.description = m.groups()[1].strip() 98 | for label in m.groups()[2].split(','): 99 | c.labels.append(label.strip()) 100 | continue 101 | 102 | m = re.match('### (.*) \((.*)\)', line) 103 | if m: 104 | c.name = m.groups()[0].strip() 105 | for label in m.groups()[1].split(','): 106 | c.labels.append(label.strip()) 107 | continue 108 | 109 | m = re.match('### (.*): (.*)', line) 110 | if m: 111 | c.name = m.groups()[0].strip() 112 | c.description = m.groups()[1].strip() 113 | continue 114 | 115 | m = re.match('### (.*)', line) 116 | if m: 117 | c.name = m.groups()[0].strip() 118 | continue 119 | 120 | raise Error('parsing failed: %s' % line) 121 | 122 | elif line.startswith('* Supporters:'): 123 | line = line.lstrip('* Supporters:') 124 | for supporter in line.split(','): 125 | c.supporters.append(supporter.strip()) 126 | 127 | elif line.startswith('* '): 128 | c.resources.append(line.lstrip('* ')) 129 | 130 | else: 131 | raise Error('parsing failed: %s' % line) 132 | 133 | candidates.append(c) 134 | return candidates 135 | 136 | def main(): 137 | try: 138 | opts, args = getopt.gnu_getopt(sys.argv[1:], 'h', ['help']) 139 | except getopt.GetoptError, e: 140 | usage(e) 141 | 142 | for opt, val in opts: 143 | if opt in ('-h', '--help'): 144 | usage() 145 | 146 | if len(args) == 0: 147 | usage() 148 | 149 | if len(args) != 1: 150 | usage('incorrect number of arguments') 151 | 152 | path = args[0] 153 | if not os.path.exists(path): 154 | fatal('path does not exist: %s' % path) 155 | 156 | candidates = parse_candidates(path) 157 | candidates = sorted(candidates, key=lambda c: c.score, reverse=True) 158 | 159 | for c in candidates: 160 | print c 161 | 162 | if __name__ == '__main__': 163 | main() 164 | --------------------------------------------------------------------------------