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
Copy file name to clipboardExpand all lines: README.md
+47-58Lines changed: 47 additions & 58 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -150,58 +150,6 @@ We have added some custom functionality to pytest which can be enabled to launch
150
150
151
151
* Pytest-django forces `settings.DEBUG` to `False` in `pytest_django/plugin.py`. To set `settings.DEBUG`, override it close to where it will be read, e.g., wit `@django.test.override_settings(DEBUG=True)`.
152
152
153
-
### Creating a new release
154
-
155
-
The stack should pass all the tests with the most recent available versions of all the dependencies.
156
-
157
-
$ cd d1_python
158
-
$ sudo ./dev_tools/src/d1_dev/pip-update-all.py
159
-
160
-
The DataONE Python stack specifies fixed versions of all its dependencies. This ensures that a stack deployed to production matches one that passed the tests. As updating the versions in the `setup.py` files manually is time consuming and error prone, a script is included that automates the task. The script updates the version information for the dependencies in the `setup.py` files to match the versions of the currently installed dependencies. Run the script with:
161
-
162
-
$ cd d1_python
163
-
$ src-sync-dependencies.py . <version>
164
-
165
-
The `<version>` argument specifies what the version will be for the release. E.g., `"2.3.1"`. We keep the version numbers in sync between all of the packages in the d1_python git repository, so only one version string needs to be specified.
166
-
167
-
Check that there are no package version conflicts:
168
-
169
-
$ pip check
170
-
171
-
Some sample files contain the version tag and must be updated when the version changes.
172
-
173
-
$ pytest --sample-ask
174
-
175
-
Commit and push the changes, and check the build on Travis.
176
-
177
-
After successful build, clone a fresh copy, which will be used for building the release packages:
Building the release packages from a fresh clone is a simple way of ensuring that only tracked files are released. It is a workaround for the way setuptools works, which is basically that it vacuums up everything that looks like a Python script in anything that looks like a package, which makes it easy to publish local files by accident.
183
-
184
-
Build and publish the packages:
185
-
186
-
cd ~/d1_python_build
187
-
setup-all.py --root . build sdist bdist_wheel
188
-
189
-
190
-
191
-
192
-
#### Update the setup.py files
193
-
194
-
195
-
#### Build the new packages
196
-
197
-
$ clean-tree.py
198
-
$ setup-all.py sdist bdist_wheel
199
-
200
-
#### Push the new packages to PyPI
201
-
202
-
TODO
203
-
204
-
205
153
### Setting up the development environment
206
154
207
155
These instructions are tested on Linux Mint 18 and should also work on close derivatives.
@@ -217,10 +165,6 @@ Download the source from GitHub:
@@ -242,12 +185,58 @@ Run the tests and verify that they all pass:
242
185
243
186
$ pytest
244
187
188
+
Set up credentials for working with the DataONE account on PyPI:
189
+
190
+
Edit `~/.pypirc`:
191
+
192
+
[server-login]
193
+
username: dataone
194
+
password: <secret>
195
+
196
+
### Creating a new release
197
+
198
+
The stack should pass all the tests with the most recent available versions of all the dependencies.
199
+
200
+
$ cd d1_python
201
+
$ sudo ./dev_tools/src/d1_dev/pip-update-all.py
202
+
203
+
The DataONE Python stack specifies fixed versions of all its dependencies. This ensures that a stack deployed to production matches one that passed the tests. As updating the versions in the `setup.py` files manually is time consuming and error prone, a script is included that automates the task. The script updates the version information for the dependencies in the `setup.py` files to match the versions of the currently installed dependencies. Run the script with:
204
+
205
+
$ cd d1_python
206
+
$ src-sync-dependencies.py . <version>
207
+
208
+
The `<version>` argument specifies what the version will be for the release. E.g., `"2.3.1"`. We keep the version numbers in sync between all of the packages in the d1_python git repository, so only one version string needs to be specified.
209
+
210
+
Check that there are no package version conflicts:
211
+
212
+
$ pip check
213
+
214
+
Some sample files contain the version tag and must be updated when the version changes.
215
+
216
+
$ pytest --sample-ask
217
+
218
+
Commit and push the changes, and check the build on Travis.
219
+
220
+
After successful build, clone a fresh copy, which will be used for building the release packages:
Building the release packages from a fresh clone is a simple way of ensuring that only tracked files are released. It is a workaround for the way setuptools works, which is basically that it vacuums up everything that looks like a Python script in anything that looks like a package, which makes it easy to publish local files by accident.
226
+
227
+
Build and publish the packages:
228
+
229
+
cd ~/d1_python_build
230
+
setup-all.py --root . bdist_wheel upload
231
+
245
232
246
233
### Building the documentation
247
234
235
+
When `d1_python` is pushed to GitHub, a signal is sent by GitHub to [ReadTheDocs.org](https://readthedocs.org/), which automatically retrieves the new version of the project from GitHub, builds the documentation and makes it available at
248
236
249
-
TODO
237
+
http://dataone-python.readthedocs.io/en/latest/
250
238
239
+
So it is not absolutely necessary to have a local build environment set up for the documentation, but building locally provides faster feedback when making changes that need to be checked before publishing.
0 commit comments