DOC/BUG: textual improvements in install docs, and fix a typo in setu…

…p.py

Address comments of @charris on numpygh-6895.

INSTALL.rst.txt

@@ -68,6 +68,12 @@ NPY_NUM_BUILD_JOBS.
 Choosing compilers
 ==================
 
+Numpy needs a C compiler, and for development versions also Cython.  A Fortran
+compiler isn't needed to build Numpy itself; the ``numpy.f2py`` tests will be
+skipped when running the test suite if no Fortran compiler is available.  For
+building Scipy a Fortran compiler is needed though, so we include some details
+on Fortran compilers in the rest of this section.
+
 On OS X and Linux, all common compilers will work.  Note that for Fortran,
 ``gfortran`` is strongly preferred over ``g77``, but if you happen to have both
 installed then ``g77`` will be detected and used first.  To explicitly select
@@ -118,19 +124,19 @@ ATLAS) will also work.
 Ubuntu/Debian
 -------------
 
-In order to build with optimized a BLAS providing development package must be installed.
-Options are for example:
+For best performance a development package providing BLAS and CBLAS should be
+installed.  Some of the options available are:
 
- - ``libblas-dev``: reference BLAS (not very optimized)
- - ``libatlas-base-dev``: generic tuned ATLAS, it is recommended to tune it to
-   the available hardware, see /usr/share/doc/libatlas3-base/README.Debian for
-   instructions
- - ``libopenblas-base``: fast and runtime detected so no tuning required but a
-   very recent version is needed (>=0.2.15 is recommended).  Older versions of
-   OpenBLAS suffered from correctness issues on some CPUs.
+- ``libblas-dev``: reference BLAS (not very optimized)
+- ``libatlas-base-dev``: generic tuned ATLAS, it is recommended to tune it to
+  the available hardware, see /usr/share/doc/libatlas3-base/README.Debian for
+  instructions
+- ``libopenblas-base``: fast and runtime detected so no tuning required but a
+  very recent version is needed (>=0.2.15 is recommended).  Older versions of
+  OpenBLAS suffered from correctness issues on some CPUs.
 
-The actual implementation can be exchanged also after installation via the
-alternatives mechanism::
+The package linked to when numpy is loaded can be chosen after installation via
+the alternatives mechanism::
 
     update-alternatives --config libblas.so.3
     update-alternatives --config liblapack.so.3

doc/source/dev/development_environment.rst

@@ -62,10 +62,9 @@ test and use your changes (in ``.py`` files), by simply restarting the
 interpreter.
 
 Note that another way to do an inplace build visible outside the repo base dir
-is with ``python setup.py develop``.  The difference is that this instead of
-adjusting ``PYTHONPATH``, this installs a ``.egg-link`` file into your
-site-packages as well as adjusts ``easy-install.pth`` there, so its a more
-permanent (and magical) operation.
+is with ``python setup.py develop``.  Instead of adjusting ``PYTHONPATH``, this
+installs a ``.egg-link`` file into your site-packages as well as adjusts the
+``easy-install.pth`` there, so its a more permanent (and magical) operation.
 
 
 Other build options

setup.py

@@ -235,14 +235,14 @@ def parse_setuppy_commands():
     # fine as they are, but are usually used together with one of the commands
     # below and not standalone.  Hence they're not added to good_commands.
     good_commands = ('develop', 'sdist', 'build', 'build_ext', 'build_py',
-                     'build_clib', 'buld_scripts', 'bdist_wheel', 'bdist_rpm',
+                     'build_clib', 'build_scripts', 'bdist_wheel', 'bdist_rpm',
                      'bdist_wininst', 'bdist_msi', 'bdist_mpkg')
 
     for command in good_commands:
         if command in sys.argv[1:]:
             return True
 
-    # The following commands are supported, but we need to show some more
+    # The following commands are supported, but we need to show more
     # useful messages to the user
     if 'install' in sys.argv[1:]:
         print(textwrap.dedent("""