You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -51,21 +47,22 @@ After reading this lesson you will:
51
47
52
48
:::
53
49
54
-
Breakout?? - You might also hear people use the term "library" the same way.
50
+
:::{todo}
51
+
You might also hear people use the term "library" the same way.
52
+
:::
55
53
56
54
## What is a Python package?
57
55
58
-
At a high level, you can think about a Python package as a toolbox.
59
56
60
-
In Python, the term package has a specific meaning: it is a directory with a certain structure. The directory contains modules which are files that end in `.py`. Each module contains functions and classes, that you can think about as tools in your toolbox.
57
+
At a high level, you can think about a Python package as a toolbox
58
+
that you can use to perform various tasks.
61
59
62
-
The modules within a package allow you to group and structure your
63
-
Python code. A package is installable, which means that you can add the functionality within
64
-
the package code to any Python environment and import that functionality like
65
-
you would import NumPy or matplotlib. This also makes it easier
66
-
to manage and reuse code across different projects.
67
-
68
-
Structuring your code as a package is the first step you need to take so you can share the tools in the toolbox you've created and let others build with it.
60
+
Structurally, in Python, a package is a directory with a specific
61
+
file structure. Within the package directory structure, there are
62
+
modules which are files that end in `.py` (the same extension you'd
63
+
see in a Python script). These modules allow you to group and
64
+
structure yourPython code. Each module contains functions and classes,
65
+
that you can think about as the tools in your toolbox.
69
66
70
67
:::{figure-md} python-toolbox
71
68
@@ -76,26 +73,41 @@ A tool may be a function or a class. Each tool does a specific thing
76
73
well.
77
74
:::
78
75
76
+
### Python packages are installable
77
+
A package is installable, which means that you can add the
78
+
functionality within the package's code to any Python environment and
79
+
import that functionality like you would import core Python packages such
80
+
as NumPy or matplotlib.
81
+
82
+
```python
83
+
import numpy
84
+
```
85
+
86
+
Installing a package into an environment makes it easier
87
+
to manage and reuse your code across different projects.
88
+
Structuring your code as a package is the first step you need to take so you can share the tools in the toolbox you've created and let others build with it.
79
89
80
90
## The elements of a Python package
81
91
82
92
:::{figure-md} package-components
83
93
84
94
<imgsrc="../images/tutorials/package-components.png"alt="Diagram showing .. more here if this stays."width="500px">
85
95
86
-
The elements of a Python package include code, documentation, tests, an OSI-approved license and a specific directory structure. Maintainers are at the core making sure everything works and is up to date while fixing bugs and addressing user concerns.
96
+
The elements of a Python package include code, documentation, tests,
97
+
an OSI-approved license and a specific directory structure.
98
+
Maintainers are at the core making sure everything works and is up to
99
+
date while fixing bugs and addressing user concerns.
87
100
:::
88
101
89
102
The core elements of Python package include:
90
103
91
104
-**Code:** Functions and classes that provide functionality for a user of your package
92
-
-**Documentation:** Installation instructions, tutorials, and examples that help users get started using your package
93
-
- Documentation also helps people to contribute to your package.
105
+
-**Documentation:** Installation instructions, tutorials, and examples that both help users get started using your package and contributors and maintainers fix bugs and maintain the package.
106
+
- Contributor Documentation in the form of a **CONTRIBUTING.md** file is useful to help people to contribute to your package.
107
+
- Development documentation helps both maintainers and contributors understand how to maintain a package's infrastructure.
94
108
-**Tests:** that makes sure your code works as it should and makes it easier for you and others to contribute to, modify and update the code in the future
95
-
-**License:** An open source license …. - link to choose a license…
96
-
-**Infrastructure** that automates updates, publication workflows and runs test suites
97
-
98
-
If you intend for others to use and contribute to your code, consider who will maintain it over time. You will want a **contributing / development** guide to help new potential contributors get started with contributing to your package, as well as a **code of conduct** to ensure community interactions remain healthy both for you and your contributors / maintainer team
109
+
-**License:** An open source license, or license that is [OSI approved](https://opensource.org/licenses/) refers to an licence that allows others to both use your package. It also provides legal direction regarding how elements of the package can and can't be reused.
110
+
-**Infrastructure** that automates updates, publication workflows and runs test suites. Infrastructure includes a suite of things such as platforms like GitHub and GitLab, tools to run tests and tools locally such as nox and tox and continuous integration that automates package maintenance steps.
99
111
100
112
:::{admonition} What pyOpenSci looks for in a package
101
113
:class: tip
@@ -104,12 +116,14 @@ pyOpenSci performs an [initial set of editor checks](https://www.pyopensci.org/s
104
116
to us for peer review.
105
117
You may find these checks useful as you create your package as a baseline for
106
118
things that you package should have.
107
-
108
119
:::
109
120
110
-
## Packages are more than just code
121
+
## Packages are more than just code - Infrastructure
111
122
112
-
A package in any language is more than just code. If your package is public facing, meaning people besides yourself will use it, you should consider the various elements of a package that make it a useful community resource.
123
+
A package in any language is more than just code. If you expect other
124
+
people to use your package, besides yourself, you should consider not
125
+
only writing high quality code, but also the various elements of a
126
+
package that make it a useful community resource.
113
127
114
128
### Version control and storing your package on GitHub or GitLab
115
129
@@ -118,7 +132,7 @@ or GitLab. GitHub and GitLab are both
118
132
run [git](https://git-scm.com/) for version control. Having your software
119
133
under version control is important because it allows you to both track changes over time while also going back in history and undoing changes in the case that a change to the code base unexpectedly breaks something.
120
134
121
-
By publishing your package on GitHub or GitLab, you are making your code public facing. This means that others can both see your code and also make contributions using a pull request (merge request in GitLab) - code review workflow.
135
+
By publishing your package on GitHub or GitLab, you are making your code public facing. This means that others can both see your code and also make contributions using a pull request (GitHub) / merge request (GitLab) / code review workflow.
122
136
123
137
:::{admonition} GitHub & GitLab vs. Git
124
138
:class: tip
@@ -128,17 +142,26 @@ software) on the backend. Running git locally on your computer allows you to
128
142
upload (`git push`) and download (`git pull`) files to GitHub and GitLab.
129
143
:::
130
144
131
-
### Continuous integration and continuous deployment help you maintain your package
145
+
### Issues or Ticket Trackers
146
+
147
+
GitHub and GitLab also both offer community features such as issues that allow:
148
+
149
+
* you to communicate with your maintainers and contributor community
150
+
* users to report bugs, ask questions and request new features
151
+
* you to publicly keep track of enhancements and features you want to work on for your package.
152
+
153
+
154
+
### Continuous integration and continuous deployment
132
155
133
-
Platforms such as GitHub and GitLab also provide continuous integration and continuous deployment (CI/CD). Continuous integration (CI) refers to a platform that automatically runs a specific job when a certain event occurs.
156
+
GitHub and GitLab also provide continuous integration and continuous deployment (CI/CD). Continuous integration (CI) refers to a platform that automatically runs a specific job when a certain event occurs.
134
157
135
158
**An example of Continuous integration:**
136
159
* When someone submits a change to your code, your tests will run across different operating systems and the code will be checked for format issues.
137
160
138
161
**An example of Continuous deployment:**
139
162
* When you are ready to release your package to PyPI, a continuous deployment operation might be triggered on release to publish your package to PyPI.
140
163
141
-
Integrated CI/CD will help you maintain your software ensuing that changes to the code don't break things unexpectedly and also maintain a style and format consistency.
164
+
Integrated CI/CD will help you maintain your software ensuing that changes to the code don't break things unexpectedly and also maintain a style and format consistency.
142
165
143
166
:::{figure-md} packaging-workflow
144
167
@@ -147,15 +170,6 @@ Integrated CI/CD will help you maintain your software ensuing that changes to t
147
170
The lifecycle of a scientific Python package.
148
171
:::
149
172
150
-
```{toctree}
151
-
:hidden:
152
-
:caption: Pre game
153
-
:glob:
154
-
extras/*
155
-
156
-
```
157
-
158
-
159
173
## What should code in a Python package look like?
160
174
161
175
Ideally the code in your Python package is general. This means it
@@ -251,6 +265,15 @@ To support your community, you'll want to add things like:
251
265
* contributing guide
252
266
253
267
268
+
269
+
270
+
:::{admonition} Support for contributors and maintainers
271
+
272
+
If you intend for others to use and contribute to your code, consider who will maintain it over time. You will want a **contributing and development** guide to help new potential contributors get started with contributing to your package, as well as a **code of conduct** to ensure community interactions remain healthy both for you and your contributors and maintainer team.
273
+
274
+
The elements above are also important for future maintenance of your package. In the case that you are no long able to maintain it or simply want extra help, development and contributing documentation will help you onboard new maintainers.
275
+
:::
276
+
254
277
<!--
255
278
Are the sections below useful??
256
279
@@ -273,21 +296,8 @@ Before you begin, think about your goals including:
273
296
- Whether you have time to add things such as documentation and tests
274
297
- How long you might be able to maintain it -->
275
298
276
-
277
299
*****
278
300
279
-
280
-
<!--
281
-
### Development guidelines
282
-
283
-
This feels really out of place here...
284
-
285
-
_TODO: I suspect nick murphy has something in this space that we can rif off of. Essentially I'm thinking here we have a SHORT section on development best practices and then link to another resource (be it on the pyos website or elsewhere). This would include things like:_
286
-
287
-
- _Defining the scope of your package and scope creep_
288
-
- _Keeping functions focused on doing a single thing well._
289
-
- _Broad generalizable get started guidelines and then we can link to more in depth resources in this space._ -->
290
-
291
301
## What's next?
292
302
293
303
In future lessons we will talk more about the infrastructure around a published Python package that makes it both easier to maintain, easier for others to contribute to and easier for other scientists to use. However, first we want to get you to your initial goal of publishing a Python package.
0 commit comments