├── .gitignore ├── CONTRIBUTE.rst ├── README.md ├── doc ├── Makefile ├── conf.py ├── contribute_to_open_source.pdf ├── how_to_sprint.rst ├── index.rst └── make.bat ├── setup.py └── sprint_tutorial ├── __init__.py ├── compute.py └── tests └── test_compute.py /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | 3 | # Byte-compiled / optimized / DLL files 4 | __pycache__/ 5 | *.py[cod] 6 | 7 | # C extensions 8 | *.so 9 | 10 | # Distribution / packaging 11 | .Python 12 | env/ 13 | build/ 14 | develop-eggs/ 15 | dist/ 16 | downloads/ 17 | eggs/ 18 | .eggs/ 19 | lib/ 20 | lib64/ 21 | parts/ 22 | sdist/ 23 | var/ 24 | *.egg-info/ 25 | .installed.cfg 26 | *.egg 27 | 28 | # PyInstaller 29 | # Usually these files are written by a python script from a template 30 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 31 | *.manifest 32 | *.spec 33 | 34 | # Installer logs 35 | pip-log.txt 36 | pip-delete-this-directory.txt 37 | 38 | # Unit test / coverage reports 39 | htmlcov/ 40 | .tox/ 41 | .coverage 42 | .coverage.* 43 | .cache 44 | nosetests.xml 45 | coverage.xml 46 | *,cover 47 | 48 | # Translations 49 | *.mo 50 | *.pot 51 | 52 | # Django stuff: 53 | *.log 54 | 55 | # Sphinx documentation 56 | docs/_build/ 57 | 58 | # PyBuilder 59 | target/ 60 | -------------------------------------------------------------------------------- /CONTRIBUTE.rst: -------------------------------------------------------------------------------- 1 | 2 | To contribute to this project, you need to make sure that: 3 | 4 | * your code is pep8 compliant, 5 | * your code has been run through pyflakes, 6 | * the test suite passes, 7 | * the documentation builds. 8 | 9 | 10 | Guidelines for contributors 11 | =========================== 12 | To learn to contribute to projects, please refer to the 13 | ``doc/how_to_sprint.rst`` documentation file. 14 | 15 | 16 | Test suite 17 | ========== 18 | The test suite is run using ``nosetests``:: 19 | 20 | $ nosetests -v sprint_tutorial 21 | 22 | 23 | Documentation 24 | ============= 25 | The documentation, in the ``doc/`` folder, must be built using sphinx:: 26 | 27 | $ cd doc 28 | $ make html 29 | 30 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Sample repository for the SciPy tutorial to learn how to sprint 3 | 4 | This repository was created to allow new sprinters to learn to 5 | contribute to a project. It also contains a document summarizing the 6 | most important steps to learn to contribute to open source Python 7 | projects. 8 | 9 | ## Learn to sprint 10 | See the ``doc/how_to_sprint.rst`` document to get started on learning how to 11 | contribute to projects during and after sprints. 12 | 13 | ## Contributing 14 | For guidelines to contribute to this project, please see the 15 | `CONTRIBUTE.rst` document. 16 | 17 | ## Dependencies 18 | This project depends on the following packages: 19 | 20 | * numpy 21 | * nose (for the test suite) 22 | * sphinx (for the documentation) 23 | * flake8 (for contributors) 24 | -------------------------------------------------------------------------------- /doc/Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | SPHINXPROJ = sprint_tutorial 8 | SOURCEDIR = . 9 | BUILDDIR = _build 10 | 11 | # Put it first so that "make" without argument is like "make help". 12 | help: 13 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 14 | 15 | .PHONY: help Makefile 16 | 17 | # Catch-all target: route all unknown targets to Sphinx using the new 18 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 19 | %: Makefile 20 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /doc/conf.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | # 3 | # sprint_tutorial documentation build configuration file, created by 4 | # sphinx-quickstart on Fri Jul 14 21:01:13 2017. 5 | # 6 | # This file is execfile()d with the current directory set to its 7 | # containing dir. 8 | # 9 | # Note that not all possible configuration values are present in this 10 | # autogenerated file. 11 | # 12 | # All configuration values have a default; values that are commented out 13 | # serve to show the default. 14 | 15 | # If extensions (or modules to document with autodoc) are in another directory, 16 | # add these directories to sys.path here. If the directory is relative to the 17 | # documentation root, use os.path.abspath to make it absolute, like shown here. 18 | # 19 | # import os 20 | # import sys 21 | # sys.path.insert(0, os.path.abspath('.')) 22 | 23 | 24 | # -- General configuration ------------------------------------------------ 25 | 26 | # If your documentation needs a minimal Sphinx version, state it here. 27 | # 28 | # needs_sphinx = '1.0' 29 | 30 | # Add any Sphinx extension module names here, as strings. They can be 31 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 32 | # ones. 33 | extensions = ['sphinx.ext.autodoc', 34 | 'sphinx.ext.doctest', 35 | 'sphinx.ext.mathjax', 36 | 'sphinx.ext.viewcode'] 37 | 38 | # Add any paths that contain templates here, relative to this directory. 39 | templates_path = ['_templates'] 40 | 41 | # The suffix(es) of source filenames. 42 | # You can specify multiple suffix as a list of string: 43 | # 44 | # source_suffix = ['.rst', '.md'] 45 | source_suffix = '.rst' 46 | 47 | # The master toctree document. 48 | master_doc = 'index' 49 | 50 | # General information about the project. 51 | project = u'sprint_tutorial' 52 | copyright = u'2017, J. Rocher' 53 | author = u'J. Rocher' 54 | 55 | # The version info for the project you're documenting, acts as replacement for 56 | # |version| and |release|, also used in various other places throughout the 57 | # built documents. 58 | # 59 | # The short X.Y version. 60 | version = u'0.0.1' 61 | # The full version, including alpha/beta/rc tags. 62 | release = u'0.0.1' 63 | 64 | # The language for content autogenerated by Sphinx. Refer to documentation 65 | # for a list of supported languages. 66 | # 67 | # This is also used if you do content translation via gettext catalogs. 68 | # Usually you set "language" from the command line for these cases. 69 | language = None 70 | 71 | # List of patterns, relative to source directory, that match files and 72 | # directories to ignore when looking for source files. 73 | # This patterns also effect to html_static_path and html_extra_path 74 | exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] 75 | 76 | # The name of the Pygments (syntax highlighting) style to use. 77 | pygments_style = 'sphinx' 78 | 79 | # If true, `todo` and `todoList` produce output, else they produce nothing. 80 | todo_include_todos = False 81 | 82 | 83 | # -- Options for HTML output ---------------------------------------------- 84 | 85 | # The theme to use for HTML and HTML Help pages. See the documentation for 86 | # a list of builtin themes. 87 | # 88 | html_theme = 'alabaster' 89 | 90 | # Theme options are theme-specific and customize the look and feel of a theme 91 | # further. For a list of options available for each theme, see the 92 | # documentation. 93 | # 94 | # html_theme_options = {} 95 | 96 | # Add any paths that contain custom static files (such as style sheets) here, 97 | # relative to this directory. They are copied after the builtin static files, 98 | # so a file named "default.css" will overwrite the builtin "default.css". 99 | html_static_path = ['_static'] 100 | 101 | 102 | # -- Options for HTMLHelp output ------------------------------------------ 103 | 104 | # Output file base name for HTML help builder. 105 | htmlhelp_basename = 'sprint_tutorialdoc' 106 | 107 | 108 | # -- Options for LaTeX output --------------------------------------------- 109 | 110 | latex_elements = { 111 | # The paper size ('letterpaper' or 'a4paper'). 112 | # 113 | # 'papersize': 'letterpaper', 114 | 115 | # The font size ('10pt', '11pt' or '12pt'). 116 | # 117 | # 'pointsize': '10pt', 118 | 119 | # Additional stuff for the LaTeX preamble. 120 | # 121 | # 'preamble': '', 122 | 123 | # Latex figure (float) alignment 124 | # 125 | # 'figure_align': 'htbp', 126 | } 127 | 128 | # Grouping the document tree into LaTeX files. List of tuples 129 | # (source start file, target name, title, 130 | # author, documentclass [howto, manual, or own class]). 131 | latex_documents = [ 132 | (master_doc, 'sprint_tutorial.tex', u'sprint\\_tutorial Documentation', 133 | u'J. Rocher', 'manual'), 134 | ] 135 | 136 | 137 | # -- Options for manual page output --------------------------------------- 138 | 139 | # One entry per manual page. List of tuples 140 | # (source start file, name, description, authors, manual section). 141 | man_pages = [ 142 | (master_doc, 'sprint_tutorial', u'sprint_tutorial Documentation', 143 | [author], 1) 144 | ] 145 | 146 | 147 | # -- Options for Texinfo output ------------------------------------------- 148 | 149 | # Grouping the document tree into Texinfo files. List of tuples 150 | # (source start file, target name, title, author, 151 | # dir menu entry, description, category) 152 | texinfo_documents = [ 153 | (master_doc, 'sprint_tutorial', u'sprint_tutorial Documentation', 154 | author, 'sprint_tutorial', 'One line description of project.', 155 | 'Miscellaneous'), 156 | ] 157 | 158 | 159 | 160 | -------------------------------------------------------------------------------- /doc/contribute_to_open_source.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jonathanrocher/sprint_tutorial/a0c018d51e0ad885fcb2ce2447c9bde006fa6141/doc/contribute_to_open_source.pdf -------------------------------------------------------------------------------- /doc/how_to_sprint.rst: -------------------------------------------------------------------------------- 1 | =============================================== 2 | How to sprint on open source projects in Python 3 | =============================================== 4 | 5 | This tutorial was given at the SciPy conference in 2016-2018 to teach people 6 | how to contribute to open source projects using the ``git`` command line tool 7 | and Github. 8 | 9 | Outline 10 | ======= 11 | 12 | #. What you need to get comfortable with 13 | #. What you need 14 | #. What you can contribute 15 | #. How to create development environments 16 | #. How to contribute code 17 | #. How to find my sprint and get setup 18 | #. What if I need more help? 19 | 20 | 21 | Contributing: what you need to get comfortable with 22 | ==================================================== 23 | 24 | * Working at the command line. 25 | * Issue workflow on Github. 26 | * Making changes and recording them using `git`. 27 | * *Good coding practices (testing frameworks, styling tools, restructured 28 | text and documentation generators). 29 | * *Debuggers and grep-type tools to find your way through new source code. 30 | 31 | Do you need to be here? No if you are already comfortable with the first 3 32 | items! 33 | 34 | 35 | What you can contribute 36 | ======================= 37 | 38 | List of ideas, requiring more and more technical knowledge of the package in 39 | question: 40 | 41 | * Documentation improvements 42 | * Tutorial review/improvements 43 | * Example review 44 | * Example creation 45 | * Add unit tests (driven by test coverage analysis) 46 | * Fix a bug 47 | * Tutorial creation 48 | * Implement new features 49 | * Review other people's PR 50 | * Close old issues not relevant anymore 51 | * Triage issues 52 | 53 | Three pieces of advice: 54 | 55 | * Your own needs are the best driver for open source contributions. 56 | * If you don't know what to do, look for issues tagged `easy`. 57 | * If you don't know what to do, ask maintainers what would be the 58 | most helpful. 59 | 60 | Next, see your sprint lead for suggestions. 61 | 62 | Contributing: what tools you need 63 | ================================= 64 | 65 | * A python aware code editor. There are many free options: Pycharm, 66 | Canopy, Spyder, emacs, vi(m), .... 67 | * An account on `github.com`. 68 | * The `git` tool. OSX: Install Xcode command line tools. 69 | Windows: https://git-scm.com/download/. Linux: use your package manager 70 | (`yum`, `apt-get`, ...). 71 | * A tool to quickly create and manage light development environments. 72 | * [OPTIONAL] A C/C++ compiler (depending on the project you want to 73 | contribute to), or a Fortran compiler. 74 | * [OPTIONAL] Several Virtual Machines running different Operating Systems to 75 | test your changes on multiple platforms. 76 | 77 | How to create development environments? 78 | ======================================= 79 | 80 | Two most reliable (free) tools to provision development environments I know: 81 | 82 | * Anaconda's ``miniconda`` 83 | * Enthought's ``EDM`` 84 | 85 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 86 | | | EDM | Miniconda | 87 | +========================+========================================================================+====================================================================+ 88 | | 1. Download | `enthought.com/products/edm `_ | `docs.conda.io `_ | 89 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 90 | | 2. Create a new env | edm environments create --version 3.6 devenv | conda create -n devenv python=3.6 | 91 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 92 | | | edm env import NEW_ENV -f bundled_env.json (1) | | 93 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 94 | | 3. Activate new envir. | edm shell -e devenv | source activate devenv | 95 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 96 | | 4. Add dependencies | edm install "numpy==1.11.3-2" scipy | conda install numpy=1.11 scipy | 97 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 98 | | | | conda install --file requirements.txt | 99 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 100 | | 5. Install package | pip install -e . | pip install -e . | 101 | +------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------+ 102 | 103 | (1) This command creates a new environment ``NEW_ENV`` from a full environment 104 | description contained in the json file (bundle). The json file can be created 105 | from an existing environment replacing ``import`` by ``export``. 106 | 107 | More help? ``edm -h`` or ``conda -h`` commands. 108 | 109 | The project contains C extensions? 110 | ---------------------------------- 111 | Some projects require a C/C++ compiler because contain C/C++ code or Cython 112 | code which needs to get compiled to be tested/distributed. 113 | 114 | * On OSX and linux, you can typically use the native compiled (gcc). Use 115 | ``yum``/``apt-get`` or OSX command line tools to install it if needed. 116 | * On Windows, ... it is a mess. For Python2.7, you need to use VS2008. For 117 | Python 3.4, you need to use VS 2010. For Python 3.5 and 3.6, you need to 118 | use VS 2015. See https://pandas.pydata.org/pandas-docs/stable/contributing.html 119 | for links to free installers. 120 | 121 | 122 | How to contribute code? 123 | ======================= 124 | 125 | The typical workflows 126 | --------------------- 127 | 128 | #. Identify a work item you want to contribute. **Think small**. 129 | 130 | #. Create a ticket for your work item **if it doesn't already exist**. 131 | 132 | #. Assign the ticket you are working on to yourself so others know it is 133 | work in progress. 134 | 135 | #. Go to the package's Github repository. Fork it into your account where you 136 | have push rights. If you are contributing to a package you have push 137 | rights for, you might skip this step. Discuss with your project 138 | lead/repository owner. 139 | 140 | #. Clone your fork locally (or the package's repository directly if you have 141 | push rights and are allowed to push branches to it directly):: 142 | 143 | git clone https://github.com//sprint_tutorial 144 | 145 | (Whichever repository you clone will represent a "remote" and be called 146 | "origin". A remote is a repository you can pull from. ``git`` allows 147 | multiple remotes to be defined on your local checked out code, in case you 148 | want to pull and push to/from different locations.) 149 | 150 | #. Create a new development environment (if not already done). Build the 151 | project into your dev environment. Run the test suite. 152 | 153 | #. Branch off to a new branch for your work item:: 154 | 155 | git branch fix/bug_name 156 | git checkout fix/bug_name 157 | 158 | or in a single step:: 159 | 160 | git checkout -b fix/bug_name 161 | 162 | (If a "commit" can be defined as a specific state of the source code you 163 | are working with, a branch can be defined as a series of commit about your 164 | targeted work. On your machine, ``git`` can track any number of branches, 165 | allowing you to work, in parallel, on any number of distinct tasks.) 166 | 167 | #. Make sure you are in the expected branch:: 168 | 169 | git branch 170 | 171 | #. Do work. **STAY FOCUSED** and only address the work item you selected. 172 | Otherwise review will be hard(er), therefore delayed, and your PR is 173 | likely to be rejected. 174 | 175 | #. Review what has been done with:: 176 | 177 | git status 178 | git diff file1.py 179 | 180 | #. When a set of changes represents a valuable step toward your goal, 181 | commit:: 182 | 183 | git commit -m "TEST: add unit test to show the bug" file1.py file2.py ... 184 | 185 | Or make a more complete commit message using an editor:: 186 | 187 | git commit file1.py file2.py ... 188 | 189 | and write the commit message in the editor ``git`` uses. 190 | 191 | #. Don't forget to include or update unit tests to make sure your work 192 | doesn't break in the future. Remember, your most important contribution 193 | might be your tests! If some code isn't unit-tested, it is either already 194 | broken, and it will be (and no one will know about it)! And run the entire 195 | test suite to make sure your contribution didn't break anything. 196 | 197 | #. Once you have done everything you want, push your branch to Github:: 198 | 199 | git push --set-upstream origin fix/bug_name 200 | 201 | or simply:: 202 | 203 | git push 204 | 205 | #. Go to Github to make a `Pull Request` (PR) with your work. You should see 206 | your branch available for a PR in both your repo and in the upstream 207 | repository that you forked. Select the branch you would like to pull your 208 | branch into, and add a complete description. 209 | 210 | #. Check for the result of Continuous Integration (CI). 211 | 212 | #. Discuss your work with your reviewer. Implement fixes and improvements, 213 | and push again to your branch. Your PR will update automatically. 214 | 215 | #. If the original package's master branch gets updated between your cloning 216 | and the time your PR is merged, you may be asked to merge master changes 217 | into your branch or rebase your branch onto the new one, and resolve any 218 | conflict. To that effect, you need to define another remote you want to 219 | pull changes from, assuming you have forked the repo. In that case, the 220 | common approach is to define the official package repo as a new remote 221 | called "upstream":: 222 | 223 | git remote add upstream git@github.com:jonathanrocher/sprint_tutorial 224 | 225 | If the project you are contributing to is ok with merges of master, it is 226 | easier to do the following:: 227 | 228 | git checkout master 229 | git pull upstream master 230 | git checkout fix/bug_name 231 | git merge master 232 | git push 233 | 234 | If your project requires to rebase:: 235 | 236 | git fetch upstream 237 | git rebase upstream/master 238 | 239 | Note that the commit hash of your current state will be changed, so if you 240 | have pushed before the rebase, your state will need to be "force-pushed":: 241 | 242 | git push --force 243 | 244 | #. Once the PR has been approved, it will be merged in the upstream project 245 | by someone who has push rights. 246 | 247 | #. After merge, there are 3 typical cleaning steps: delete the branch on the 248 | remote repositories (in Github), update master locally from upstream, 249 | update master in your own fork and delete the work branch locally.:: 250 | 251 | git checkout master 252 | git pull upstream master 253 | git push origin master 254 | git branch -d fix/bug_name 255 | 256 | #. GOTO 1. 257 | 258 | 259 | Check-list before making a PR and requesting review. 260 | ---------------------------------------------------- 261 | 262 | That check-list depends on each project, but typically, you should think of the 263 | following: 264 | 265 | * Tests pass on your machine (try as many OSs as possible). 266 | * Code conforms to pylint/flake8/pep8/styling. 267 | * All new functions and classes have docstrings. 268 | * Your branch is sync-ed with current master. 269 | * CI tests are all green. 270 | * Documentation is updated (if needed). 271 | * Changelog is updated (if needed). 272 | 273 | 274 | When things go wrong with git 275 | ----------------------------- 276 | Git is an incredibly powerful tool to manage code, but it is pretty easy to 277 | mess up. It is ok, everyone messes up with ``git``. The good news is, you can 278 | (almost) always recover from a mess up. If you have an issue, pause, think, 279 | google, find a git guru! 280 | 281 | Here are a few tricks to get out of common situations: 282 | 283 | * You have made a mess and want to erase all un-committed code (ALL FILES):: 284 | 285 | git reset --hard HEAD 286 | 287 | * You have made a mess in only 1 file:: 288 | 289 | git checkout HEAD -- filename 290 | 291 | * You have committed too quickly, and want to include more files, or redo your 292 | commit message:: 293 | 294 | git reset --soft HEAD^ 295 | 296 | * You don't like where you are going and decide you want to go back in time, 297 | to a precise commit, look for the commit hash with:: 298 | 299 | git log 300 | 301 | and then reset to that point:: 302 | 303 | git reset --hard 304 | 305 | You can also go back in time without loosing your work since then, just to 306 | check things out:: 307 | 308 | git checkout 309 | 310 | * You have pulled master or a collaborator's work and now have a conflict? 311 | Open the conflicted file in an editor, and merge lines manually. Then:: 312 | 313 | git add filename 314 | 315 | to mark it as resolved. Your branch is back to being ready to be committed. 316 | 317 | * You would like to pause your work in progress without committing to do 318 | something else or switch to another branch that has conflicts:: 319 | 320 | git stash 321 | 322 | When you are done, and want your changes back:: 323 | 324 | git stash pop 325 | 326 | Note that you can stash multiple times. States are stored on a stack 327 | (FILO). 328 | 329 | 330 | What's next? 331 | ============ 332 | 333 | Look for your sprint in http://bit.ly/sprints2018 . Get yourself setup as much 334 | as possible using information there. Then, head down and connect with your 335 | sprint lead. 336 | 337 | 338 | Where to get more help? 339 | ======================= 340 | 341 | * Your sprint leader 342 | * The project's contributing guidelines (see column H of http://bit.ly/sprints2018 ) 343 | * The project's `travis.yml` file. 344 | * Sprint help on slack: `sprints` channel at http://scipy2018.slack.com 345 | * Contribution workflow: https://pandas.pydata.org/pandas-docs/stable/contributing.html 346 | * Numpy testing guidelines: https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt 347 | * Numpy docstring guidelines: https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt 348 | * Restructured text primer: http://docutils.sourceforge.net/docs/user/rst/quickref.html 349 | -------------------------------------------------------------------------------- /doc/index.rst: -------------------------------------------------------------------------------- 1 | .. sprint_tutorial documentation master file, created by 2 | sphinx-quickstart on Fri Jul 14 21:01:13 2017. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Welcome to sprint_tutorial's documentation! 7 | =========================================== 8 | 9 | .. toctree:: 10 | :maxdepth: 2 11 | :caption: Contents: 12 | 13 | how_to_sprint.rst 14 | 15 | 16 | 17 | Indices and tables 18 | ================== 19 | 20 | * :ref:`genindex` 21 | * :ref:`modindex` 22 | * :ref:`search` 23 | -------------------------------------------------------------------------------- /doc/make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | pushd %~dp0 4 | 5 | REM Command file for Sphinx documentation 6 | 7 | if "%SPHINXBUILD%" == "" ( 8 | set SPHINXBUILD=sphinx-build 9 | ) 10 | set SOURCEDIR=. 11 | set BUILDDIR=_build 12 | set SPHINXPROJ=sprint_tutorial 13 | 14 | if "%1" == "" goto help 15 | 16 | %SPHINXBUILD% >NUL 2>NUL 17 | if errorlevel 9009 ( 18 | echo. 19 | echo.The 'sphinx-build' command was not found. Make sure you have Sphinx 20 | echo.installed, then set the SPHINXBUILD environment variable to point 21 | echo.to the full path of the 'sphinx-build' executable. Alternatively you 22 | echo.may add the Sphinx directory to PATH. 23 | echo. 24 | echo.If you don't have Sphinx installed, grab it from 25 | echo.http://sphinx-doc.org/ 26 | exit /b 1 27 | ) 28 | 29 | %SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% 30 | goto end 31 | 32 | :help 33 | %SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% 34 | 35 | :end 36 | popd 37 | -------------------------------------------------------------------------------- /setup.py: -------------------------------------------------------------------------------- 1 | from os.path import dirname, join 2 | from setuptools import setup 3 | 4 | 5 | def read(fname): 6 | return open(join(dirname(__file__), fname)).read() 7 | 8 | 9 | setup( 10 | name = "sprint_tutorial", 11 | version = "0.0.1", 12 | author = "Jonathan Rocher", 13 | author_email = "jonathanrocher@gmail.com", 14 | description = ("Sample repository to learn to sprint on open source " 15 | "software"), 16 | license = "BSD", 17 | keywords = "example sprint tutorial", 18 | url = "https://github.com/jonathanrocher/sprint_tutorial", 19 | packages=['sprint_tutorial'], 20 | long_description=read('README.md'), 21 | classifiers=[ 22 | "Topic :: Utilities", 23 | "License :: OSI Approved :: BSD License", 24 | ], 25 | ) 26 | -------------------------------------------------------------------------------- /sprint_tutorial/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jonathanrocher/sprint_tutorial/a0c018d51e0ad885fcb2ce2447c9bde006fa6141/sprint_tutorial/__init__.py -------------------------------------------------------------------------------- /sprint_tutorial/compute.py: -------------------------------------------------------------------------------- 1 | """ Module to compute stuff 2 | """ 3 | 4 | 5 | def my_sum(x, y): 6 | """ Compute the sum of 2 numbers 7 | """ 8 | return 2*(x + y) 9 | -------------------------------------------------------------------------------- /sprint_tutorial/tests/test_compute.py: -------------------------------------------------------------------------------- 1 | """ Tests for the compute module 2 | """ 3 | from nose.tools import assert_equal 4 | 5 | from sprint_tutorial.compute import my_sum 6 | 7 | 8 | def test_my_sum1(): 9 | assert_equal(my_sum(0, 0), 0) 10 | 11 | 12 | def test_my_sum2(): 13 | assert_equal(my_sum(1, -1), 0) 14 | 15 | 16 | def test_my_sum3(): 17 | assert_equal(my_sum(1, 1), 2) 18 | --------------------------------------------------------------------------------