|
2 | 2 |
|
3 | 3 | ## What is this? |
4 | 4 |
|
5 | | -This template codifies LINCC-Framework's best practices for python code organization, testing, documentation, and automation. |
| 5 | +This project template codifies LINCC-Framework's best practices for python code organization, testing, documentation, and automation. It is meant to help new python projects get started quickly, letting the user focus on writing code. The template takes care of the minutia of directory structures, tool configurations, and automated testing until the user is ready to take over. |
6 | 6 |
|
7 | | -## How to use this Copier template: |
| 7 | +[Copier](https://copier.readthedocs.io/en/latest/) is required to use this template. Copier is an open source tool that hydrates projects from templates and natively supports updating projects as the original template matures. It's really neat! |
8 | 8 |
|
9 | | -1) Install Python 3.7 or newer. (Check with `python --version`) |
10 | | -2) Install Git 2.27 or new. (Check with `git --version`) |
11 | | -3) Install `copier` like so: `pipx install copier`. (`pip` works fine too, but `pipx` is what the cool kids use) |
12 | | -4) Create a new project using this template like so: `copier gh:lincc-frameworks/python-project-template <path/to/destination>` |
13 | | -5) Provide answers to the prompts |
14 | | -6) Enjoy pure, uncut euphoria. |
15 | 9 |
|
16 | | -## Post-euphoria - Install your new package |
| 10 | +# Getting started |
17 | 11 |
|
18 | | -Ok, ok, calm down. I know, it's really great. |
19 | | -You should go ahead and install your new project using these instructions: |
20 | | -1) Create a new environment with your choice of environment managers (conda, virtualenv, etc.) |
21 | | -2) Install the base dependencies: `pip install .` |
22 | | -3) Install the extra developer dependencies: `pip install '.[dev]'` (Note - the single quotes around '.[dev]' may not be required for your system.) |
| 12 | +## Prerequisites |
23 | 13 |
|
24 | | -## Version control and keeping your project up to date |
| 14 | +These prerequisites for Copier are defined [here](https://copier.readthedocs.io/en/latest/#installation). |
| 15 | +1) Python > 3.7 |
| 16 | +2) Git > 2.27 |
| 17 | +3) pipx (nice to have, conda and pip work too, but can be more difficult to reason about later) |
25 | 18 |
|
26 | | -### Setup version control for your newly created project |
| 19 | +``` |
| 20 | +>> python --version |
| 21 | +Python 3.10.9 |
27 | 22 |
|
28 | | -To appreciate the full power of Copier, push your newly created project into a github repository. There are lots of ways to do this, and but every environment is a snowflake. |
29 | | -Fortunately, there are several how-to's available. Roughly speaking, the sequence of commands is: |
30 | | -1) Run `git init`[^1] in your newly created project |
31 | | -2) Run `git add .` to add all your new files and directories. |
32 | | -3) Run `git commit` with a nice message. |
33 | | -4) Create a new remote repository ([GitHub How-to](https://docs.github.com/en/get-started/quickstart/create-a-repo)) |
34 | | -5) Run `git remote ad origin https://github.com/<the_remote_project>/<the_remote_repository>` |
35 | | -6) Run `git push origin <local_branch_name>` |
| 23 | +>> git --version |
| 24 | +git version 2.34.1 |
| 25 | +
|
| 26 | +>> which pipx |
| 27 | +/usr/bin/pipx |
| 28 | +``` |
| 29 | + |
| 30 | +## Install Copier |
| 31 | + |
| 32 | +Given that you have all the prerequisites satisfied, go ahead and install Copier. |
| 33 | +``` |
| 34 | +>> pipx install copier |
| 35 | +``` |
| 36 | + |
| 37 | +## Create a new project from the template |
| 38 | + |
| 39 | +Choose where you would like to create your new project, and call copier with the template. |
| 40 | +``` |
| 41 | +>> copier gh:lincc-frameworks/python-project-template <path/to/destination> |
| 42 | +``` |
| 43 | + |
| 44 | +After providing answers to the prompts, Copier will hydrate a project template and save it in the specified location. |
| 45 | + |
| 46 | +## Create a new environment and install your new package |
| 47 | + |
| 48 | +Create a new environment with your choice of environment tools (virtualenv, conda, etc.). Activate it, and change into the package directory. |
| 49 | + |
| 50 | +Install the newly created python package. Use `pip` to install both the standard set of dependencies as well as the `[dev]` dependencies. (Note: depending on your system, you may not need the single quotes about '.[dev]') |
| 51 | +``` |
| 52 | +>> pip install -e . |
| 53 | +... |
| 54 | +Lots of output |
| 55 | +... |
| 56 | +
|
| 57 | +>> pip install '.[dev]' |
| 58 | +... |
| 59 | +Lots more output |
| 60 | +... |
| 61 | +``` |
| 62 | + |
| 63 | +## Register pre-commit hooks |
| 64 | + |
| 65 | +The tool `pre-commit` is an industry standard that will execute a set of tests prior to completing a git commit action. For instance, pre-commit can run unit tests to verify code coverage or linters to ensure adherence to style guides. Pre-commit documentation can be found [here](https://pre-commit.com/index.html). |
| 66 | + |
| 67 | +``` |
| 68 | +>> pre-commit install |
| 69 | +``` |
| 70 | + |
| 71 | +## Add local version control to your project |
| 72 | + |
| 73 | +The process of setting up _local_ version control will look something like this: |
| 74 | + |
| 75 | +``` |
| 76 | +>> git init[^1] |
| 77 | +Initialized empty Git repository in /path/to/destination/.git/ |
| 78 | +>> git checkout -b initial_branch |
| 79 | +Switched to a new branch 'initial_branch' |
| 80 | +>> git add . |
| 81 | +>> git commit -m 'Initial commit' |
| 82 | +``` |
36 | 83 |
|
37 | 84 | [^1]: If you haven't already, you can run `git config --global init.defaultBranch <name>` so that your default branch name isn't `master`. |
38 | 85 |
|
39 | | -### Keep your project up to date with changes to the original template. |
| 86 | +## Extra Credit - Push your work to GitHub |
40 | 87 |
|
41 | | -Once the project is under version control you'll be able to keep your project up to date by running `copier update`. |
42 | | -Copier will automatically check to see if a newer version of the original template is available and if so the changes will then be automatically applied to your project. Neato! |
| 88 | +Create a new repository in GitHub: ([GitHub How-to](https://docs.github.com/en/get-started/quickstart/create-a-repo)) |
| 89 | + |
| 90 | +``` |
| 91 | +>> git remote add origin https://github.com/<the_remote_project>/<the_remote_repository> |
| 92 | +>> git push origin <local_branch_name> |
| 93 | +``` |
| 94 | + |
| 95 | +Notice that when you create a PR in GitHub, a set of tests for Continuous Integration starts up to verify that the project can build successfully and that all the unit tests pass. Neato! |
| 96 | + |
| 97 | + |
| 98 | +# Some nifty things you get for free |
| 99 | + |
| 100 | +## Keep your project up to date as the original template evolves |
| 101 | + |
| 102 | +Once your project is under version control you'll be able to keep your project up to date by running `copier update`. |
| 103 | + |
| 104 | +Copier will automatically check to see if a newer version of the original template is available and if so the changes will be automatically applied. Neato! |
43 | 105 |
|
44 | 106 | And of course, because your project is under version control, if you don't like the new changes, you can always revert back to the previous state. :) |
45 | 107 |
|
46 | | -## Other neat peices that come for free |
| 108 | +## GitHub CI is ready out of the box |
| 109 | + |
| 110 | +Notice that this template contains a `.github/workflows` directory with a `python-package.yml` file. Because of this, any project created from this template that uses GitHub as a repository will automatically have CI enabled. |
47 | 111 |
|
48 | | -### GitHub CI is ready out of the box |
| 112 | +GitHub workflows are extremely useful, for more information, check out the [About workflows](https://docs.github.com/en/actions/using-workflows/about-workflows) page. |
49 | 113 |
|
50 | | -Notice that this template contains a `.github/workflows` directory with a `python-package.yml` file. So any project created from this template that uses github as a repository will automatically have CI enabled. GitHub workflows are extremely useful, for more information, check out the [About workflows](https://docs.github.com/en/actions/using-workflows/about-workflows) page. |
| 114 | +## Pre-commit is part of it too |
51 | 115 |
|
52 | | -### Pre-commit is part of it too |
| 116 | +No one wants the embarrassment of committing a .py file without a trailing blank line :scream: You'll immediately have access to [pre-commit](https://pre-commit.com/), an industry standard third-party tool. |
53 | 117 |
|
54 | | -Once you have created a new project from the template, and start coding, you can save yourself from the embarassment of say, not including a blank line at the end of your .py file, by using pre-commit checks. |
55 | | -After you have successfully run `pip install '.[dev]'` as part of the "Post-euphoria - Install your new package" step, run `pre-commit install`. |
56 | | -This will register all the pre-commit git hooks defined in .pre-commit-config.yaml with git so that they are run before a `git commit` is completed. |
| 118 | +Using pre-commit before GitHub workflows start allows you to do a quick check of your code before it's committed. This cuts down on code feedback time, and allows for faster development. |
57 | 119 |
|
58 | | -This functionality relies on a the third-party tool, [pre-commit](https://pre-commit.com/). It's a very useful tool when paired with Github workflows. Since the workflows will typically prevent code merging if certain tests fail, by using pre-commit, the user can verify that their code will pass all the workflow checks prior to completing a git commit. |
| 120 | +# Contributing to the Template |
59 | 121 |
|
60 | | -# Developement of the template |
| 122 | +## Find (or make) a new GitHub issue |
61 | 123 |
|
62 | | -## Making updates to the template |
| 124 | +Add yourself as the assignee on an existing issue so that we know who's working on what. ( If you're not actively working on an issue, unassign yourself :wink: ) |
63 | 125 |
|
64 | | -Feel free to make updates to this template. Once you've tested the updates you should create a new release to make them available. GitHub's [instructions](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) for doing so are here. Use your best judgement when incrementing the version. |
| 126 | +If there isn't an issue for the work you want to do, please create one and include a description - it's just polite. |
| 127 | + |
| 128 | +## Create a branch |
| 129 | + |
| 130 | +It is preferable that you create a new branch with a name like `issue/##/<short-description>`. GitHub makes it pretty easy to associate branches and tickets, but it's just easier when it's in the name. |
65 | 131 |
|
66 | 132 | ## Testing the template |
67 | 133 |
|
68 | | -Testing can be tricky. The current best way is to clone this repository locally, and generate test projects locally, and verify your expected results. To be clear though, if there's an opportunity for automated tests, please take advantage of it. |
| 134 | +Testing can be tricky. The current best way is to clone this repository locally, and use Copier to generate a test project locally, then verify your expected results. |
| 135 | + |
| 136 | +Copier will look for git tags to determine which version of the template to use. You probably don't want to create new tags while you're working on the template. Create a test project using this signature to let Copier know to use the latest local version. See the [Copier documentation](https://copier.readthedocs.io/en/latest/generating/#regenerating-a-project) for more information. |
| 137 | + |
| 138 | +``` |
| 139 | +>> copier --vcs-ref HEAD </local/path/to/template> </test/project/directory> |
| 140 | +``` |
| 141 | +Notes: |
| 142 | +1) Any changes to the template will need to be committed (**not pushed**) to be picked up by Copier. |
| 143 | +2) If there's an opportunity for introducing an automated test, please take it. |
| 144 | + |
| 145 | +## Create your PR |
| 146 | + |
| 147 | +To be able to move quickly, there aren't many guardrails right now to prevent merging bad code. This will change as the project becomes more mature. For now, please use PR best practices, and get someone to review your code. |
| 148 | + |
| 149 | +## Optional - Release a new version |
| 150 | + |
| 151 | +Once you've tested the updates you should create a new release to make them available. GitHub's [instructions](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) for doing so are here. Use your best judgement when incrementing the version. i.e. is this a major, minor, or patch fix. |
0 commit comments