Skip to content

Commit 3968ff9

Browse files
authored
Merge pull request #23 from lincc-frameworks/issue/9/cleanup-readme
Overhaul of the README file
2 parents d9a826e + 360d94c commit 3968ff9

3 files changed

Lines changed: 143 additions & 47 deletions

File tree

.pre-commit-config.yaml

Lines changed: 20 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -32,16 +32,29 @@ repos:
3232

3333
# verify that pyproject.toml is well formed
3434
- repo: https://github.com/abravalheri/validate-pyproject
35-
rev: main
35+
rev: v0.12.1
3636
hooks:
3737
- id: validate-pyproject
3838
name: Validate syntax of pyproject.toml
3939
description: Verify that pyproject.toml adheres to the established schema.
4040

4141
# Automatically sort the imports used in .py files
42-
- repo: https://github.com/pycqa/isort
43-
rev: 5.12.0
44-
hooks:
45-
- id: isort
46-
name: isort (python)
47-
description: Sort and organize imports in .py files.
42+
- repo: https://github.com/pycqa/isort
43+
rev: 5.12.0
44+
hooks:
45+
- id: isort
46+
name: isort (python)
47+
description: Sort and organize imports in .py files.
48+
49+
- repo: local
50+
hooks:
51+
- id: pylint
52+
name: pylint
53+
entry: pylint
54+
language: system
55+
types: [python]
56+
args:
57+
[
58+
"-rn", # Only display messages
59+
"-sn", # Don't display the score
60+
]

README.md

Lines changed: 122 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -2,67 +2,150 @@
22

33
## What is this?
44

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.
66

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!
88

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.
159

16-
## Post-euphoria - Install your new package
10+
# Getting started
1711

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
2313

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)
2518

26-
### Setup version control for your newly created project
19+
```
20+
>> python --version
21+
Python 3.10.9
2722
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+
```
3683

3784
[^1]: If you haven't already, you can run `git config --global init.defaultBranch <name>` so that your default branch name isn't `master`.
3885

39-
### Keep your project up to date with changes to the original template.
86+
## Extra Credit - Push your work to GitHub
4087

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!
43105

44106
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. :)
45107

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.
47111

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.
49113

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
51115

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.
53117

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.
57119

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
59121

60-
# Developement of the template
122+
## Find (or make) a new GitHub issue
61123

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: )
63125

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.
65131

66132
## Testing the template
67133

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.

tests/{{module_name}}_tests/test_example_module.py.jinja

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,4 +9,4 @@ def test_greetings():
99
def test_meaning():
1010
"""Verify the output of the `meaning` function"""
1111
output = example_module.meaning()
12-
assert output == 42
12+
assert output == 42

0 commit comments

Comments
 (0)