Show More
@@ -1,284 +1,295 b'' | |||
|
1 | 1 | # -*- coding: utf-8 -*- |
|
2 | 2 | # |
|
3 | 3 | # IPython documentation build configuration file. |
|
4 | 4 | |
|
5 | 5 | # NOTE: This file has been edited manually from the auto-generated one from |
|
6 | 6 | # sphinx. Do NOT delete and re-generate. If any changes from sphinx are |
|
7 | 7 | # needed, generate a scratch one and merge by hand any new fields needed. |
|
8 | 8 | |
|
9 | 9 | # |
|
10 | 10 | # This file is execfile()d with the current directory set to its containing dir. |
|
11 | 11 | # |
|
12 | 12 | # The contents of this file are pickled, so don't put values in the namespace |
|
13 | 13 | # that aren't pickleable (module imports are okay, they're removed automatically). |
|
14 | 14 | # |
|
15 | 15 | # All configuration values have a default value; values that are commented out |
|
16 | 16 | # serve to show the default value. |
|
17 | 17 | |
|
18 | 18 | import sys, os |
|
19 | 19 | |
|
20 | 20 | ON_RTD = os.environ.get('READTHEDOCS', None) == 'True' |
|
21 | 21 | |
|
22 | 22 | if ON_RTD: |
|
23 | 23 | # Mock the presence of matplotlib, which we don't have on RTD |
|
24 | 24 | # see |
|
25 | 25 | # http://read-the-docs.readthedocs.io/en/latest/faq.html |
|
26 | 26 | tags.add('rtd') |
|
27 | 27 | |
|
28 | 28 | # RTD doesn't use the Makefile, so re-run autogen_{things}.py here. |
|
29 | 29 | for name in ('config', 'api', 'magics', 'shortcuts'): |
|
30 | 30 | fname = 'autogen_{}.py'.format(name) |
|
31 | 31 | fpath = os.path.abspath(os.path.join('..', fname)) |
|
32 | 32 | with open(fpath) as f: |
|
33 | 33 | exec(compile(f.read(), fname, 'exec'), { |
|
34 | 34 | '__file__': fpath, |
|
35 | 35 | '__name__': '__main__', |
|
36 | 36 | }) |
|
37 | 37 | else: |
|
38 | 38 | import sphinx_rtd_theme |
|
39 | 39 | html_theme = "sphinx_rtd_theme" |
|
40 | 40 | html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] |
|
41 | 41 | |
|
42 | 42 | # If your extensions are in another directory, add it here. If the directory |
|
43 | 43 | # is relative to the documentation root, use os.path.abspath to make it |
|
44 | 44 | # absolute, like shown here. |
|
45 | 45 | sys.path.insert(0, os.path.abspath('../sphinxext')) |
|
46 | 46 | |
|
47 | 47 | # We load the ipython release info into a dict by explicit execution |
|
48 | 48 | iprelease = {} |
|
49 | 49 | exec(compile(open('../../IPython/core/release.py').read(), '../../IPython/core/release.py', 'exec'),iprelease) |
|
50 | 50 | |
|
51 | 51 | # General configuration |
|
52 | 52 | # --------------------- |
|
53 | 53 | |
|
54 | 54 | # Add any Sphinx extension module names here, as strings. They can be extensions |
|
55 | 55 | # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. |
|
56 | 56 | extensions = [ |
|
57 | 57 | 'matplotlib.sphinxext.mathmpl', |
|
58 | 58 | 'matplotlib.sphinxext.only_directives', |
|
59 | 59 | 'matplotlib.sphinxext.plot_directive', |
|
60 | 60 | 'sphinx.ext.autodoc', |
|
61 | 61 | 'sphinx.ext.autosummary', |
|
62 | 62 | 'sphinx.ext.doctest', |
|
63 | 63 | 'sphinx.ext.inheritance_diagram', |
|
64 | 64 | 'sphinx.ext.intersphinx', |
|
65 | 65 | 'IPython.sphinxext.ipython_console_highlighting', |
|
66 | 66 | 'IPython.sphinxext.ipython_directive', |
|
67 | 67 | 'sphinx.ext.napoleon', # to preprocess docstrings |
|
68 | 68 | 'github', # for easy GitHub links |
|
69 | 69 | 'magics', |
|
70 | 70 | ] |
|
71 | 71 | |
|
72 | 72 | if ON_RTD: |
|
73 | 73 | # Remove extensions not currently supported on RTD |
|
74 | 74 | extensions.remove('matplotlib.sphinxext.only_directives') |
|
75 | 75 | extensions.remove('matplotlib.sphinxext.mathmpl') |
|
76 | 76 | extensions.remove('matplotlib.sphinxext.plot_directive') |
|
77 | 77 | extensions.remove('IPython.sphinxext.ipython_directive') |
|
78 | 78 | extensions.remove('IPython.sphinxext.ipython_console_highlighting') |
|
79 | 79 | |
|
80 | 80 | # Add any paths that contain templates here, relative to this directory. |
|
81 | 81 | templates_path = ['_templates'] |
|
82 | 82 | |
|
83 | 83 | # The suffix of source filenames. |
|
84 | 84 | source_suffix = '.rst' |
|
85 | 85 | |
|
86 | rst_prolog = '' | |
|
87 | ||
|
86 | 88 | def is_stable(extra): |
|
87 | 89 | for ext in {'dev', 'b', 'rc'}: |
|
88 | 90 | if ext in extra: |
|
89 | 91 | return False |
|
90 | 92 | return True |
|
91 | 93 | |
|
92 | 94 | if is_stable(iprelease['_version_extra']): |
|
93 | 95 | tags.add('ipystable') |
|
94 | 96 | else: |
|
95 | 97 | tags.add('ipydev') |
|
96 | rst_prolog = """ | |
|
97 |
|
|
|
98 | rst_prolog += """ | |
|
99 | .. warning:: | |
|
100 | ||
|
101 | This documentation is for a development version of IPython. There may be | |
|
102 | significant differences from the latest stable release. | |
|
103 | """ | |
|
104 | ||
|
105 | rst_prolog += """ | |
|
106 | .. important:: | |
|
98 | 107 | |
|
99 | This documentation is for a development version of IPython. There may be | |
|
100 | significant differences from the latest stable release. | |
|
108 | This is the documentation for IPython version > 6.0 which is had | |
|
109 | stopped compatibility for python version lower than 3.3. If you are | |
|
110 | looking for a version of IPython compatible with python 2.7 please see | |
|
111 | the documentation for the IPython 5.x LTS (Long term support branch) | |
|
101 | 112 | |
|
102 |
|
|
|
113 | """ | |
|
103 | 114 | |
|
104 | 115 | # The master toctree document. |
|
105 | 116 | master_doc = 'index' |
|
106 | 117 | |
|
107 | 118 | # General substitutions. |
|
108 | 119 | project = 'IPython' |
|
109 | 120 | copyright = 'The IPython Development Team' |
|
110 | 121 | |
|
111 | 122 | # ghissue config |
|
112 | 123 | github_project_url = "https://github.com/ipython/ipython" |
|
113 | 124 | |
|
114 | 125 | # numpydoc config |
|
115 | 126 | numpydoc_show_class_members = False # Otherwise Sphinx emits thousands of warnings |
|
116 | 127 | numpydoc_class_members_toctree = False |
|
117 | 128 | |
|
118 | 129 | # The default replacements for |version| and |release|, also used in various |
|
119 | 130 | # other places throughout the built documents. |
|
120 | 131 | # |
|
121 | 132 | # The full version, including alpha/beta/rc tags. |
|
122 | 133 | release = "%s" % iprelease['version'] |
|
123 | 134 | # Just the X.Y.Z part, no '-dev' |
|
124 | 135 | version = iprelease['version'].split('-', 1)[0] |
|
125 | 136 | |
|
126 | 137 | |
|
127 | 138 | # There are two options for replacing |today|: either, you set today to some |
|
128 | 139 | # non-false value, then it is used: |
|
129 | 140 | #today = '' |
|
130 | 141 | # Else, today_fmt is used as the format for a strftime call. |
|
131 | 142 | today_fmt = '%B %d, %Y' |
|
132 | 143 | |
|
133 | 144 | # List of documents that shouldn't be included in the build. |
|
134 | 145 | #unused_docs = [] |
|
135 | 146 | |
|
136 | 147 | # Exclude these glob-style patterns when looking for source files. They are |
|
137 | 148 | # relative to the source/ directory. |
|
138 | 149 | exclude_patterns = ['whatsnew/pr'] |
|
139 | 150 | |
|
140 | 151 | |
|
141 | 152 | # If true, '()' will be appended to :func: etc. cross-reference text. |
|
142 | 153 | #add_function_parentheses = True |
|
143 | 154 | |
|
144 | 155 | # If true, the current module name will be prepended to all description |
|
145 | 156 | # unit titles (such as .. function::). |
|
146 | 157 | #add_module_names = True |
|
147 | 158 | |
|
148 | 159 | # If true, sectionauthor and moduleauthor directives will be shown in the |
|
149 | 160 | # output. They are ignored by default. |
|
150 | 161 | #show_authors = False |
|
151 | 162 | |
|
152 | 163 | # The name of the Pygments (syntax highlighting) style to use. |
|
153 | 164 | pygments_style = 'sphinx' |
|
154 | 165 | |
|
155 | 166 | # Set the default role so we can use `foo` instead of ``foo`` |
|
156 | 167 | default_role = 'literal' |
|
157 | 168 | |
|
158 | 169 | # Options for HTML output |
|
159 | 170 | # ----------------------- |
|
160 | 171 | |
|
161 | 172 | # The style sheet to use for HTML and HTML Help pages. A file of that name |
|
162 | 173 | # must exist either in Sphinx' static/ path, or in one of the custom paths |
|
163 | 174 | # given in html_static_path. |
|
164 | 175 | # html_style = 'default.css' |
|
165 | 176 | |
|
166 | 177 | |
|
167 | 178 | # The name for this set of Sphinx documents. If None, it defaults to |
|
168 | 179 | # "<project> v<release> documentation". |
|
169 | 180 | #html_title = None |
|
170 | 181 | |
|
171 | 182 | # The name of an image file (within the static path) to place at the top of |
|
172 | 183 | # the sidebar. |
|
173 | 184 | #html_logo = None |
|
174 | 185 | |
|
175 | 186 | # Add any paths that contain custom static files (such as style sheets) here, |
|
176 | 187 | # relative to this directory. They are copied after the builtin static files, |
|
177 | 188 | # so a file named "default.css" will overwrite the builtin "default.css". |
|
178 | 189 | html_static_path = ['_static'] |
|
179 | 190 | |
|
180 | 191 | # Favicon needs the directory name |
|
181 | 192 | html_favicon = '_static/favicon.ico' |
|
182 | 193 | # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, |
|
183 | 194 | # using the given strftime format. |
|
184 | 195 | html_last_updated_fmt = '%b %d, %Y' |
|
185 | 196 | |
|
186 | 197 | # If true, SmartyPants will be used to convert quotes and dashes to |
|
187 | 198 | # typographically correct entities. |
|
188 | 199 | #html_use_smartypants = True |
|
189 | 200 | |
|
190 | 201 | # Custom sidebar templates, maps document names to template names. |
|
191 | 202 | #html_sidebars = {} |
|
192 | 203 | |
|
193 | 204 | # Additional templates that should be rendered to pages, maps page names to |
|
194 | 205 | # template names. |
|
195 | 206 | html_additional_pages = { |
|
196 | 207 | 'interactive/htmlnotebook': 'notebook_redirect.html', |
|
197 | 208 | 'interactive/notebook': 'notebook_redirect.html', |
|
198 | 209 | 'interactive/nbconvert': 'notebook_redirect.html', |
|
199 | 210 | 'interactive/public_server': 'notebook_redirect.html', |
|
200 | 211 | } |
|
201 | 212 | |
|
202 | 213 | # If false, no module index is generated. |
|
203 | 214 | #html_use_modindex = True |
|
204 | 215 | |
|
205 | 216 | # If true, the reST sources are included in the HTML build as _sources/<name>. |
|
206 | 217 | #html_copy_source = True |
|
207 | 218 | |
|
208 | 219 | # If true, an OpenSearch description file will be output, and all pages will |
|
209 | 220 | # contain a <link> tag referring to it. The value of this option must be the |
|
210 | 221 | # base URL from which the finished HTML is served. |
|
211 | 222 | #html_use_opensearch = '' |
|
212 | 223 | |
|
213 | 224 | # If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). |
|
214 | 225 | #html_file_suffix = '' |
|
215 | 226 | |
|
216 | 227 | # Output file base name for HTML help builder. |
|
217 | 228 | htmlhelp_basename = 'ipythondoc' |
|
218 | 229 | |
|
219 | 230 | intersphinx_mapping = {'python': ('https://docs.python.org/3/', None), |
|
220 | 231 | 'rpy2': ('https://rpy2.readthedocs.io/en/version_2.8.x/', None), |
|
221 | 232 | 'traitlets': ('https://traitlets.readthedocs.io/en/latest/', None), |
|
222 | 233 | 'jupyterclient': ('https://jupyter-client.readthedocs.io/en/latest/', None), |
|
223 | 234 | 'ipyparallel': ('https://ipyparallel.readthedocs.io/en/latest/', None), |
|
224 | 235 | 'jupyter': ('https://jupyter.readthedocs.io/en/latest/', None), |
|
225 | 236 | } |
|
226 | 237 | |
|
227 | 238 | # Options for LaTeX output |
|
228 | 239 | # ------------------------ |
|
229 | 240 | |
|
230 | 241 | # The paper size ('letter' or 'a4'). |
|
231 | 242 | latex_paper_size = 'letter' |
|
232 | 243 | |
|
233 | 244 | # The font size ('10pt', '11pt' or '12pt'). |
|
234 | 245 | latex_font_size = '11pt' |
|
235 | 246 | |
|
236 | 247 | # Grouping the document tree into LaTeX files. List of tuples |
|
237 | 248 | # (source start file, target name, title, author, document class [howto/manual]). |
|
238 | 249 | |
|
239 | 250 | latex_documents = [ |
|
240 | 251 | ('index', 'ipython.tex', 'IPython Documentation', |
|
241 | 252 | u"""The IPython Development Team""", 'manual', True), |
|
242 | 253 | ('parallel/winhpc_index', 'winhpc_whitepaper.tex', |
|
243 | 254 | 'Using IPython on Windows HPC Server 2008', |
|
244 | 255 | u"Brian E. Granger", 'manual', True) |
|
245 | 256 | ] |
|
246 | 257 | |
|
247 | 258 | # The name of an image file (relative to this directory) to place at the top of |
|
248 | 259 | # the title page. |
|
249 | 260 | #latex_logo = None |
|
250 | 261 | |
|
251 | 262 | # For "manual" documents, if this is true, then toplevel headings are parts, |
|
252 | 263 | # not chapters. |
|
253 | 264 | #latex_use_parts = False |
|
254 | 265 | |
|
255 | 266 | # Additional stuff for the LaTeX preamble. |
|
256 | 267 | #latex_preamble = '' |
|
257 | 268 | |
|
258 | 269 | # Documents to append as an appendix to all manuals. |
|
259 | 270 | #latex_appendices = [] |
|
260 | 271 | |
|
261 | 272 | # If false, no module index is generated. |
|
262 | 273 | latex_use_modindex = True |
|
263 | 274 | |
|
264 | 275 | |
|
265 | 276 | # Options for texinfo output |
|
266 | 277 | # -------------------------- |
|
267 | 278 | |
|
268 | 279 | texinfo_documents = [ |
|
269 | 280 | (master_doc, 'ipython', 'IPython Documentation', |
|
270 | 281 | 'The IPython Development Team', |
|
271 | 282 | 'IPython', |
|
272 | 283 | 'IPython Documentation', |
|
273 | 284 | 'Programming', |
|
274 | 285 | 1), |
|
275 | 286 | ] |
|
276 | 287 | |
|
277 | 288 | modindex_common_prefix = ['IPython.'] |
|
278 | 289 | |
|
279 | 290 | |
|
280 | 291 | # Cleanup |
|
281 | 292 | # ------- |
|
282 | 293 | # delete release info to avoid pickling errors from sphinx |
|
283 | 294 | |
|
284 | 295 | del iprelease |
@@ -1,246 +1,252 b'' | |||
|
1 | 1 | .. _release_process: |
|
2 | 2 | |
|
3 | 3 | ======================= |
|
4 | 4 | IPython release process |
|
5 | 5 | ======================= |
|
6 | 6 | |
|
7 | 7 | This document contains the process that is used to create an IPython release. |
|
8 | 8 | |
|
9 | 9 | Conveniently, the ``release`` script in the ``tools`` directory of the ``IPython`` |
|
10 | 10 | repository automates most of the release process. This document serves as a |
|
11 | 11 | handy reminder and checklist for the release manager. |
|
12 | 12 | |
|
13 | 13 | During the release process, you might need the extra following dependencies: |
|
14 | 14 | |
|
15 | 15 | - ``keyring`` to access your GitHub authentication tokens |
|
16 | 16 | - ``graphviz`` to generate some graphs in the documentation |
|
17 | 17 | |
|
18 | 18 | Make sure you have all the required dependencies to run the tests as well. |
|
19 | 19 | |
|
20 | 20 | |
|
21 | 21 | 1. Set Environment variables |
|
22 | 22 | ---------------------------- |
|
23 | 23 | |
|
24 | 24 | Set environment variables to document previous release tag, current |
|
25 | 25 | release milestone, current release version, and git tag. |
|
26 | 26 | |
|
27 | 27 | These variables may be used later to copy/paste as answers to the script |
|
28 | 28 | questions instead of typing the appropriate command when the time comes. These |
|
29 | 29 | variables are not used by the scripts directly; therefore, there is no need to |
|
30 | 30 | ``export`` them. The format for bash is as follows, but note that these values |
|
31 | 31 | are just an example valid only for the 5.0 release; you'll need to update them |
|
32 | 32 | for the release you are actually making:: |
|
33 | 33 | |
|
34 | 34 | PREV_RELEASE=4.2.1 |
|
35 | 35 | MILESTONE=5.0 |
|
36 | 36 | VERSION=5.0.0 |
|
37 | 37 | BRANCH=master |
|
38 | 38 | |
|
39 | 39 | |
|
40 | 40 | 2. Create GitHub stats and finish release note |
|
41 | 41 | ---------------------------------------------- |
|
42 | 42 | |
|
43 | 43 | .. note:: |
|
44 | 44 | |
|
45 | 45 | This step is optional if making a Beta or RC release. |
|
46 | 46 | |
|
47 | 47 | .. note:: |
|
48 | 48 | |
|
49 | 49 | Before generating the GitHub stats, verify that all closed issues and pull |
|
50 | 50 | requests have `appropriate milestones |
|
51 | 51 | <https://github.com/ipython/ipython/wiki/Dev%3A-GitHub-workflow#milestones>`_. |
|
52 | 52 | `This search |
|
53 | 53 | <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_ |
|
54 | 54 | should return no results before creating the GitHub stats. |
|
55 | 55 | |
|
56 | 56 | If a major release: |
|
57 | 57 | |
|
58 | 58 | - merge any pull request notes into what's new:: |
|
59 | 59 | |
|
60 | 60 | python tools/update_whatsnew.py |
|
61 | 61 | |
|
62 | 62 | - update ``docs/source/whatsnew/development.rst``, to ensure it covers |
|
63 | 63 | the major release features |
|
64 | 64 | |
|
65 | 65 | - move the contents of ``development.rst`` to ``versionX.rst`` where ``X`` is |
|
66 | 66 | the numerical release version |
|
67 | 67 | |
|
68 | 68 | - generate summary of GitHub contributions, which can be done with:: |
|
69 | 69 | |
|
70 | 70 | python tools/github_stats.py --milestone $MILESTONE > stats.rst |
|
71 | 71 | |
|
72 | 72 | which may need some manual cleanup of ``stats.rst``. Add the cleaned |
|
73 | 73 | ``stats.rst`` results to ``docs/source/whatsnew/github-stats-X.rst`` |
|
74 | 74 | where ``X`` is the numerical release version (don't forget to add it to |
|
75 | 75 | the git repo as well). If creating a major release, make a new |
|
76 | 76 | ``github-stats-X.rst`` file; if creating a minor release, the content |
|
77 | 77 | from ``stats.rst`` may simply be added to the top of an existing |
|
78 | 78 | ``github-stats-X.rst`` file. Finally, edit |
|
79 | 79 | ``docs/source/whatsnew/index.rst`` to list the new ``github-stats-X`` |
|
80 | 80 | file you just created and remove temporarily the first entry called |
|
81 | 81 | ``development`` (you'll need to add it back after release). |
|
82 | 82 | |
|
83 | 83 | Make sure that the stats file has a header or it won't be rendered in |
|
84 | 84 | the final documentation. |
|
85 | 85 | |
|
86 | 86 | To find duplicates and update `.mailmap`, use:: |
|
87 | 87 | |
|
88 | 88 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f |
|
89 | 89 | |
|
90 | 90 | 3. Make sure the repository is clean |
|
91 | 91 | ------------------------------------ |
|
92 | 92 | |
|
93 | 93 | of any file that could be problematic. |
|
94 | 94 | Remove all non-tracked files with: |
|
95 | 95 | |
|
96 | 96 | .. code:: |
|
97 | 97 | |
|
98 | 98 | git clean -xfdi |
|
99 | 99 | |
|
100 | 100 | This will ask for confirmation before removing all untracked files. Make |
|
101 | 101 | sure the ``dist/`` folder is clean to avoid any stale builds from |
|
102 | 102 | previous build attempts. |
|
103 | 103 | |
|
104 | 104 | |
|
105 | 105 | 4. Update the release version number |
|
106 | 106 | ------------------------------------ |
|
107 | 107 | |
|
108 | 108 | Edit ``IPython/core/release.py`` to have the current version. |
|
109 | 109 | |
|
110 | 110 | in particular, update version number and ``_version_extra`` content in |
|
111 | 111 | ``IPython/core/release.py``. |
|
112 | 112 | |
|
113 | 113 | Step 5 will validate your changes automatically, but you might still want to |
|
114 | 114 | make sure the version number matches pep440. |
|
115 | 115 | |
|
116 | 116 | In particular, ``rc`` and ``beta`` are not separated by ``.`` or the ``sdist`` |
|
117 | 117 | and ``bdist`` will appear as different releases. For example, a valid version |
|
118 | 118 | number for a release candidate (rc) release is: ``1.3rc1``. Notice that there |
|
119 | 119 | is no separator between the '3' and the 'r'. Check the environment variable |
|
120 | 120 | ``$VERSION`` as well. |
|
121 | 121 | |
|
122 | 122 | You will likely just have to modify/comment/uncomment one of the lines setting |
|
123 | 123 | ``_version_extra`` |
|
124 | 124 | |
|
125 | 125 | |
|
126 | 126 | 5. Run the `tools/build_release` script |
|
127 | 127 | --------------------------------------- |
|
128 | 128 | |
|
129 | 129 | Running ``tools/build_release`` does all the file checking and building that |
|
130 | 130 | the real release script will do. This makes test installations, checks that |
|
131 | 131 | the build procedure runs OK, and tests other steps in the release process. |
|
132 | 132 | |
|
133 | 133 | The ``build_release`` script will in particular verify that the version number |
|
134 | 134 | match PEP 440, in order to avoid surprise at the time of build upload. |
|
135 | 135 | |
|
136 | 136 | We encourage creating a test build of the docs as well. |
|
137 | 137 | |
|
138 | 138 | 6. Create and push the new tag |
|
139 | 139 | ------------------------------ |
|
140 | 140 | |
|
141 | 141 | Commit the changes to release.py:: |
|
142 | 142 | |
|
143 | 143 | git commit -am "release $VERSION" |
|
144 | 144 | git push origin $BRANCH |
|
145 | 145 | |
|
146 | 146 | Create and push the tag:: |
|
147 | 147 | |
|
148 | 148 | git tag -am "release $VERSION" "$VERSION" |
|
149 | 149 | git push origin --tags |
|
150 | 150 | |
|
151 | 151 | Update release.py back to ``x.y-dev`` or ``x.y-maint``, and re-add the |
|
152 | 152 | ``development`` entry in ``docs/source/whatsnew/index.rst`` and push:: |
|
153 | 153 | |
|
154 | 154 | git commit -am "back to development" |
|
155 | 155 | git push origin $BRANCH |
|
156 | 156 | |
|
157 | 157 | 7. Get a fresh clone |
|
158 | 158 | -------------------- |
|
159 | 159 | |
|
160 | 160 | Get a fresh clone of the tag for building the release:: |
|
161 | 161 | |
|
162 | 162 | cd /tmp |
|
163 | 163 | git clone --depth 1 https://github.com/ipython/ipython.git -b "$VERSION" |
|
164 | 164 | cd ipython |
|
165 | 165 | |
|
166 | 166 | .. note:: |
|
167 | 167 | |
|
168 | 168 | You can aslo cleanup the current working repository with ``git clean -xfdi`` |
|
169 | 169 | |
|
170 | 170 | 8. Run the release script |
|
171 | 171 | ------------------------- |
|
172 | 172 | |
|
173 | .. important:: | |
|
174 | ||
|
175 | Following releases instructions have information to release IPython 5.x and | |
|
176 | 6.x both on python 2 and python 3. When reasing IPython 6+, ignore the step | |
|
177 | for python2. | |
|
178 | ||
|
173 | 179 | Run the ``release`` script, this step requires having a current wheel, Python |
|
174 | 180 | >=3.4 and Python 2.7.:: |
|
175 | 181 | |
|
176 | 182 | ./tools/release |
|
177 | 183 | |
|
178 | 184 | This makes the tarballs, zipfiles, and wheels, and put them under the ``dist/`` |
|
179 | 185 | folder. Be sure to test the ``wheels`` and the ``sdist`` locally before |
|
180 | 186 | uploading them to PyPI. We do not use an universal wheel as each wheel |
|
181 | 187 | installs an ``ipython2`` or ``ipython3`` script, depending on the version of |
|
182 | 188 | Python it is built for. Using an universal wheel would prevent this. |
|
183 | 189 | |
|
184 | 190 | Use the following to actually upload the result of the build:: |
|
185 | 191 | |
|
186 | 192 | ./tools/release upload |
|
187 | 193 | |
|
188 | 194 | It should posts them to ``archive.ipython.org``. |
|
189 | 195 | |
|
190 | 196 | You will need to use `twine <https://github.com/pypa/twine>`_ ) manually to |
|
191 | 197 | actually upload on PyPI. Unlike setuptools, twine is able to upload packages |
|
192 |
over SSL |
|
|
198 | over SSL:: | |
|
193 | 199 |
|
|
194 | 200 | twine upload dist/* |
|
195 | 201 | |
|
196 | 202 |
|
|
197 | 203 | PyPI/Warehouse will automatically hide previous releases. If you are uploading |
|
198 | 204 | a non-stable version, make sure to log-in to PyPI and un-hide previous version. |
|
199 | 205 | |
|
200 | 206 | |
|
201 | 207 | 9. Draft a short release announcement |
|
202 | 208 | ------------------------------------- |
|
203 | 209 | |
|
204 | 210 | The announcement should include: |
|
205 | 211 | |
|
206 | 212 | - release highlights |
|
207 | 213 | - a link to the html version of the *What's new* section of the documentation |
|
208 | 214 | - a link to upgrade or installation tips (if necessary) |
|
209 | 215 | |
|
210 | 216 | Post the announcement to the mailing list and or blog, and link from Twitter. |
|
211 | 217 | |
|
212 | 218 | .. note:: |
|
213 | 219 | |
|
214 | 220 | If you are doing a RC or Beta, you can likely skip the next steps. |
|
215 | 221 | |
|
216 | 222 | 10. Update milestones on GitHub |
|
217 | 223 | ------------------------------- |
|
218 | 224 | |
|
219 | 225 | These steps will bring milestones up to date: |
|
220 | 226 | |
|
221 | 227 | - close the just released milestone |
|
222 | 228 | - open a new milestone for the next release (x, y+1), if the milestone doesn't |
|
223 | 229 | exist already |
|
224 | 230 | |
|
225 | 231 | 11. Update the IPython website |
|
226 | 232 | ------------------------------ |
|
227 | 233 | |
|
228 | 234 | The IPython website should document the new release: |
|
229 | 235 | |
|
230 | 236 | - add release announcement (news, announcements) |
|
231 | 237 | - update current version and download links |
|
232 | 238 | - update links on the documentation page (especially if a major release) |
|
233 | 239 | |
|
234 | 240 | 12. Update readthedocs |
|
235 | 241 | ---------------------- |
|
236 | 242 | |
|
237 | 243 | Make sure to update readthedocs and set the latest tag as stable, as well as |
|
238 | 244 | checking that previous release is still building under its own tag. |
|
239 | 245 | |
|
240 | 246 | |
|
241 | 247 | 13. Celebrate! |
|
242 | 248 | -------------- |
|
243 | 249 | |
|
244 | 250 | Celebrate the release and please thank the contributors for their work. Great |
|
245 | 251 | job! |
|
246 | 252 |
@@ -1,255 +1,256 b'' | |||
|
1 | 1 | .. _overview: |
|
2 | 2 | |
|
3 | 3 | ======== |
|
4 | 4 | Overview |
|
5 | 5 | ======== |
|
6 | 6 | |
|
7 | 7 | One of Python's most useful features is its interactive interpreter. |
|
8 | 8 | It allows for very fast testing of ideas without the overhead of |
|
9 | 9 | creating test files as is typical in most programming languages. |
|
10 | 10 | However, the interpreter supplied with the standard Python distribution |
|
11 | 11 | is somewhat limited for extended interactive use. |
|
12 | 12 | |
|
13 | 13 | The goal of IPython is to create a comprehensive environment for |
|
14 | 14 | interactive and exploratory computing. To support this goal, IPython |
|
15 | 15 | has three main components: |
|
16 | 16 | |
|
17 | 17 | * An enhanced interactive Python shell. |
|
18 | 18 | |
|
19 | 19 | * A decoupled :ref:`two-process communication model <ipythonzmq>`, which |
|
20 | 20 | allows for multiple clients to connect to a computation kernel, most notably |
|
21 | 21 | the web-based notebook provided with `Jupyter <https://jupyter.org>`_. |
|
22 | 22 | |
|
23 | 23 | * An architecture for interactive parallel computing now part of the |
|
24 | 24 | `ipyparallel` package. |
|
25 | 25 | |
|
26 | 26 | All of IPython is open source (released under the revised BSD license). |
|
27 | 27 | |
|
28 | 28 | Enhanced interactive Python shell |
|
29 | 29 | ================================= |
|
30 | 30 | |
|
31 | 31 | IPython's interactive shell (:command:`ipython`), has the following goals, |
|
32 | 32 | amongst others: |
|
33 | 33 | |
|
34 | 34 | 1. Provide an interactive shell superior to Python's default. IPython |
|
35 | 35 | has many features for tab-completion, object introspection, system shell |
|
36 | 36 | access, command history retrieval across sessions, and its own special |
|
37 | 37 | command system for adding functionality when working interactively. It |
|
38 | 38 | tries to be a very efficient environment both for Python code development |
|
39 | 39 | and for exploration of problems using Python objects (in situations like |
|
40 | 40 | data analysis). |
|
41 | 41 | |
|
42 | 42 | 2. Serve as an embeddable, ready to use interpreter for your own |
|
43 | 43 | programs. An interactive IPython shell can be started with a single call |
|
44 | 44 | from inside another program, providing access to the current namespace. |
|
45 | 45 | This can be very useful both for debugging purposes and for situations |
|
46 | 46 | where a blend of batch-processing and interactive exploration are needed. |
|
47 | 47 | |
|
48 | 48 | 3. Offer a flexible framework which can be used as the base |
|
49 | 49 | environment for working with other systems, with Python as the underlying |
|
50 | 50 | bridge language. Specifically scientific environments like Mathematica, |
|
51 | 51 | IDL and Matlab inspired its design, but similar ideas can be |
|
52 | 52 | useful in many fields. |
|
53 | 53 | |
|
54 | 54 | 4. Allow interactive testing of threaded graphical toolkits. IPython |
|
55 | 55 | has support for interactive, non-blocking control of GTK, Qt, WX, GLUT, and |
|
56 | 56 | OS X applications via special threading flags. The normal Python |
|
57 | 57 | shell can only do this for Tkinter applications. |
|
58 | 58 | |
|
59 | 59 | Main features of the interactive shell |
|
60 | 60 | -------------------------------------- |
|
61 | 61 | |
|
62 | 62 | * Dynamic object introspection. One can access docstrings, function |
|
63 | 63 | definition prototypes, source code, source files and other details |
|
64 | 64 | of any object accessible to the interpreter with a single |
|
65 | 65 | keystroke (:samp:`?`, and using :samp:`??` provides additional detail). |
|
66 | 66 | |
|
67 | 67 | * Searching through modules and namespaces with :samp:`*` wildcards, both |
|
68 | 68 | when using the :samp:`?` system and via the :samp:`%psearch` command. |
|
69 | 69 | |
|
70 | 70 | * Completion in the local namespace, by typing :kbd:`TAB` at the prompt. |
|
71 | 71 | This works for keywords, modules, methods, variables and files in the |
|
72 | 72 | current directory. This is supported via the ``prompt_toolkit`` library. |
|
73 | 73 | Custom completers can be implemented easily for different purposes |
|
74 | 74 | (system commands, magic arguments etc.) |
|
75 | 75 | |
|
76 | 76 | * Numbered input/output prompts with command history (persistent |
|
77 | 77 | across sessions and tied to each profile), full searching in this |
|
78 | 78 | history and caching of all input and output. |
|
79 | 79 | |
|
80 | 80 | * User-extensible 'magic' commands. A set of commands prefixed with |
|
81 | 81 | :samp:`%` or :samp:`%%` is available for controlling IPython itself and provides |
|
82 | 82 | directory control, namespace information and many aliases to |
|
83 | 83 | common system shell commands. |
|
84 | 84 | |
|
85 | 85 | * Alias facility for defining your own system aliases. |
|
86 | 86 | |
|
87 | 87 | * Complete system shell access. Lines starting with :samp:`!` are passed |
|
88 | 88 | directly to the system shell, and using :samp:`!!` or :samp:`var = !cmd` |
|
89 | 89 | captures shell output into python variables for further use. |
|
90 | 90 | |
|
91 | 91 | * The ability to expand python variables when calling the system shell. In a |
|
92 | 92 | shell command, any python variable prefixed with :samp:`$` is expanded. A |
|
93 | 93 | double :samp:`$$` allows passing a literal :samp:`$` to the shell (for access |
|
94 | 94 | to shell and environment variables like :envvar:`PATH`). |
|
95 | 95 | |
|
96 | 96 | * Filesystem navigation, via a magic :samp:`%cd` command, along with a |
|
97 | 97 | persistent bookmark system (using :samp:`%bookmark`) for fast access to |
|
98 | 98 | frequently visited directories. |
|
99 | 99 | |
|
100 | 100 | * A lightweight persistence framework via the :samp:`%store` command, which |
|
101 | 101 | allows you to save arbitrary Python variables. These get restored |
|
102 | 102 | when you run the :samp:`%store -r` command. |
|
103 | 103 | |
|
104 | 104 | * Automatic indentation and highlighting of code as you type (through the |
|
105 | 105 | `prompt_toolkit` library). |
|
106 | 106 | |
|
107 | 107 | * Macro system for quickly re-executing multiple lines of previous |
|
108 | 108 | input with a single name via the :samp:`%macro` command. Macros can be |
|
109 | 109 | stored persistently via :samp:`%store` and edited via :samp:`%edit`. |
|
110 | 110 | |
|
111 | 111 | * Session logging (you can then later use these logs as code in your |
|
112 | 112 | programs). Logs can optionally timestamp all input, and also store |
|
113 | 113 | session output (marked as comments, so the log remains valid |
|
114 | 114 | Python source code). |
|
115 | 115 | |
|
116 | 116 | * Session restoring: logs can be replayed to restore a previous |
|
117 | 117 | session to the state where you left it. |
|
118 | 118 | |
|
119 | 119 | * Verbose and colored exception traceback printouts. Easier to parse |
|
120 | 120 | visually, and in verbose mode they produce a lot of useful |
|
121 | 121 | debugging information (basically a terminal version of the cgitb |
|
122 | 122 | module). |
|
123 | 123 | |
|
124 | 124 | * Auto-parentheses via the :samp:`%autocall` command: callable objects can be |
|
125 | 125 | executed without parentheses: :samp:`sin 3` is automatically converted to |
|
126 | 126 | :samp:`sin(3)` |
|
127 | 127 | |
|
128 | 128 | * Auto-quoting: using :samp:`,`, or :samp:`;` as the first character forces |
|
129 | 129 | auto-quoting of the rest of the line: :samp:`,my_function a b` becomes |
|
130 | 130 | automatically :samp:`my_function("a","b")`, while :samp:`;my_function a b` |
|
131 | 131 | becomes :samp:`my_function("a b")`. |
|
132 | 132 | |
|
133 | 133 | * Extensible input syntax. You can define filters that pre-process |
|
134 | 134 | user input to simplify input in special situations. This allows |
|
135 | 135 | for example pasting multi-line code fragments which start with |
|
136 | 136 | :samp:`>>>` or :samp:`...` such as those from other python sessions or the |
|
137 | 137 | standard Python documentation. |
|
138 | 138 | |
|
139 | 139 | * Flexible :ref:`configuration system <config_overview>`. It uses a |
|
140 | 140 | configuration file which allows permanent setting of all command-line |
|
141 | 141 | options, module loading, code and file execution. The system allows |
|
142 | 142 | recursive file inclusion, so you can have a base file with defaults and |
|
143 | 143 | layers which load other customizations for particular projects. |
|
144 | 144 | |
|
145 | 145 | * Embeddable. You can call IPython as a python shell inside your own |
|
146 | 146 | python programs. This can be used both for debugging code or for |
|
147 | 147 | providing interactive abilities to your programs with knowledge |
|
148 | 148 | about the local namespaces (very useful in debugging and data |
|
149 | 149 | analysis situations). |
|
150 | 150 | |
|
151 | 151 | * Easy debugger access. You can set IPython to call up an enhanced version of |
|
152 | 152 | the Python debugger (pdb) every time there is an uncaught exception. This |
|
153 | 153 | drops you inside the code which triggered the exception with all the data |
|
154 | 154 | live and it is possible to navigate the stack to rapidly isolate the source |
|
155 | 155 | of a bug. The :samp:`%run` magic command (with the :samp:`-d` option) can run |
|
156 | 156 | any script under pdb's control, automatically setting initial breakpoints for |
|
157 | 157 | you. This version of pdb has IPython-specific improvements, including |
|
158 | 158 | tab-completion and traceback coloring support. For even easier debugger |
|
159 | 159 | access, try :samp:`%debug` after seeing an exception. |
|
160 | 160 | |
|
161 | 161 | * Profiler support. You can run single statements (similar to |
|
162 | 162 | :samp:`profile.run()`) or complete programs under the profiler's control. |
|
163 | 163 | While this is possible with standard cProfile or profile modules, |
|
164 | 164 | IPython wraps this functionality with magic commands (see :samp:`%prun` |
|
165 | 165 | and :samp:`%run -p`) convenient for rapid interactive work. |
|
166 | 166 | |
|
167 | 167 | * Simple timing information. You can use the :samp:`%timeit` command to get |
|
168 | 168 | the execution time of a Python statement or expression. This machinery is |
|
169 | 169 | intelligent enough to do more repetitions for commands that finish very |
|
170 | 170 | quickly in order to get a better estimate of their running time. |
|
171 | 171 | |
|
172 | 172 | .. sourcecode:: ipython |
|
173 | 173 | |
|
174 | 174 | In [1]: %timeit 1+1 |
|
175 | 175 | 10000000 loops, best of 3: 25.5 ns per loop |
|
176 | 176 | |
|
177 | 177 | In [2]: %timeit [math.sin(x) for x in range(5000)] |
|
178 | 178 | 1000 loops, best of 3: 719 Β΅s per loop |
|
179 | 179 | |
|
180 | 180 | .. |
|
181 | 181 | |
|
182 | 182 | To get the timing information for more than one expression, use the |
|
183 | 183 | :samp:`%%timeit` cell magic command. |
|
184 | 184 | |
|
185 | 185 | |
|
186 | 186 | * Doctest support. The special :samp:`%doctest_mode` command toggles a mode |
|
187 | 187 | to use doctest-compatible prompts, so you can use IPython sessions as |
|
188 | 188 | doctest code. By default, IPython also allows you to paste existing |
|
189 | 189 | doctests, and strips out the leading :samp:`>>>` and :samp:`...` prompts in |
|
190 | 190 | them. |
|
191 | 191 | |
|
192 | 192 | .. _ipythonzmq: |
|
193 | 193 | |
|
194 | 194 | Decoupled two-process model |
|
195 | 195 | ============================== |
|
196 | 196 | |
|
197 | 197 | IPython has abstracted and extended the notion of a traditional |
|
198 | 198 | *Read-Evaluate-Print Loop* (REPL) environment by decoupling the *evaluation* |
|
199 | 199 | into its own process. We call this process a **kernel**: it receives execution |
|
200 | 200 | instructions from clients and communicates the results back to them. |
|
201 | 201 | |
|
202 | 202 | This decoupling allows us to have several clients connected to the same |
|
203 | 203 | kernel, and even allows clients and kernels to live on different machines. |
|
204 | 204 | With the exclusion of the traditional single process terminal-based IPython |
|
205 | 205 | (what you start if you run ``ipython`` without any subcommands), all |
|
206 | 206 | other IPython machinery uses this two-process model. Most of this is now part |
|
207 | 207 | of the `Jupyter` project, whis includes ``jupyter console``, ``jupyter |
|
208 | 208 | qtconsole``, and ``jupyter notebook``. |
|
209 | 209 | |
|
210 | 210 | As an example, this means that when you start ``jupyter qtconsole``, you're |
|
211 | 211 | really starting two processes, a kernel and a Qt-based client can send |
|
212 | 212 | commands to and receive results from that kernel. If there is already a kernel |
|
213 | 213 | running that you want to connect to, you can pass the ``--existing`` flag |
|
214 | 214 | which will skip initiating a new kernel and connect to the most recent kernel, |
|
215 | 215 | instead. To connect to a specific kernel once you have several kernels |
|
216 | 216 | running, use the ``%connect_info`` magic to get the unique connection file, |
|
217 | 217 | which will be something like ``--existing kernel-19732.json`` but with |
|
218 | 218 | different numbers which correspond to the Process ID of the kernel. |
|
219 | 219 | |
|
220 | 220 | You can read more about using `jupyter qtconsole |
|
221 | 221 | <http://jupyter.org/qtconsole/>`_, and |
|
222 | 222 | `jupyter notebook <http://jupyter-notebook.readthedocs.io/en/latest/>`_. There |
|
223 | 223 | is also a :ref:`message spec <messaging>` which documents the protocol for |
|
224 | 224 | communication between kernels |
|
225 | 225 | and clients. |
|
226 | 226 | |
|
227 | 227 | .. seealso:: |
|
228 | 228 | |
|
229 | 229 | `Frontend/Kernel Model`_ example notebook |
|
230 | 230 | |
|
231 | 231 | |
|
232 | 232 | Interactive parallel computing |
|
233 | 233 | ============================== |
|
234 | 234 | |
|
235 | 235 | |
|
236 | 236 | This functionality is optional and now part of the `ipyparallel |
|
237 | 237 | <http://ipyparallel.readthedocs.io/>`_ project. |
|
238 | 238 | |
|
239 | 239 | Portability and Python requirements |
|
240 | 240 | ----------------------------------- |
|
241 | 241 | |
|
242 |
|
|
|
242 | Version 6.0 of IPython work with python 3.3 and above. | |
|
243 | Version 2.0 to 5 works with Python 2.7 and 3.3 or above. | |
|
243 | 244 | Version 1.0 additionally worked with Python 2.6 and 3.2. |
|
244 | 245 | Version 0.12 was the first version to fully support Python 3. |
|
245 | 246 | |
|
246 | 247 | IPython is known to work on the following operating systems: |
|
247 | 248 | |
|
248 | 249 | * Linux |
|
249 | 250 | * Most other Unix-like OSs (AIX, Solaris, BSD, etc.) |
|
250 | 251 | * Mac OS X |
|
251 | 252 | * Windows (CygWin, XP, Vista, etc.) |
|
252 | 253 | |
|
253 | 254 | See :ref:`here <install_index>` for instructions on how to install IPython. |
|
254 | 255 | |
|
255 | 256 | .. include:: links.txt |
General Comments 0
You need to be logged in to leave comments.
Login now