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
Here you will find guidelines for what we look for in your scientific
32
-
Python package when reviewing. You will also find best practice recommendations and curated lists of community resources surrounding packaging and package documentation.
33
-
34
115
### pyOpenSci's packaging goals
35
116
36
117
Our goal is to help the
37
118
community make decisions around how to create scientific Python packages. We are working towards a shared vision of packaging that helps users better understand where to start.
38
119
39
120
### How this guide is created
40
121
41
-
This guide is created by pyOpenSci through an extensive review process. Each page in the guide has been reviewed by experts in the broader Python packaging landscape including people from:
122
+
This guide is created by pyOpenSci through an extensive review process. Each page in the guide has been reviewed by experts in the broader Python packaging landscape including people from:
42
123
43
124
- conda & conda-forge
44
125
- the python packaging authority
@@ -152,35 +233,3 @@ Good meets the requirements. Going beyond the minimum can make package maintenan
152
233
153
234
This guide is now a work in progress. If you have ideas of things you'd like
154
235
to see here, [we invite you to open an issue on GitHub that details any changes or additions that you'd like to see.](https://github.com/pyOpenSci/python-package-guide/issues).
155
-
156
-
<!--
157
-
COMMENTED OUT TEXT TO BE MOVED
158
-
159
-
160
-
# TODO LINK TO CI BUILDS FOR Documentation>
161
-
Maybe we can curate a list of CI builds that people can use??? or is that moving too close to a cookie cutter situation
162
-
163
-
The text below is being moved to the packaging infrastructure section which
164
-
doesn't exist YET... but will soon .
165
-
pyOpenSci packages must:
166
-
167
-
- Contain full documentation for any user-facing functions.
168
-
- Have a test suite that covers the major functionality of the package.
169
-
- Use continuous integration.
170
-
- Use an OSI approved software license.
171
-
172
-
173
-
## Other recommendations
174
-
### Python version support
175
-
You should always be explicit about which versions of Python your package supports.
176
-
Keeping compatibility with old Python versions can be difficult as functionality changes.
177
-
A good rule of thumb is that the package should support, at least,
178
-
the latest three Python versions (e.g., 3.8, 3.7, 3.6).
179
-
180
-
### Code Style
181
-
pyOpenSci encourages authors to consult [PEP 8](https://www.python.org/dev/peps/pep-0008/) for information on how to style your code.
182
-
183
-
### Linting
184
-
An automatic linter (e.g. flake8) can help ensure your code is clean and free of syntax errors. These can be integrated with your CI.
0 commit comments