DOC: Switch to https where used

Switch links to https

Author: bashtage

.travis.yml

@@ -94,7 +94,7 @@ notifications:
 
 # Setup anaconda
 before_install:
-  - wget http://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh
+  - wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh
   - chmod +x miniconda.sh
   - ./miniconda.sh -b -p /home/travis/miniconda
   - export PATH=/home/travis/miniconda/bin:$PATH

CHANGES.md

@@ -1,4 +1,4 @@
 Release Notes
 =============
 
-The list of changes for each statsmodels release can be found [here](http://www.statsmodels.org/devel/release/index.html). Full details are available in the [commit logs](https://github.com/statsmodels/statsmodels).
+The list of changes for each statsmodels release can be found [here](https://www.statsmodels.org/devel/release/index.html). Full details are available in the [commit logs](https://github.com/statsmodels/statsmodels).

CONTRIBUTING.rst

@@ -20,8 +20,8 @@ Making Changes to the Code
 For a pull request to be accepted, you must meet the below requirements. This greatly helps in keeping the job of maintaining and releasing the software a shared effort.
 
 - **One branch. One feature.** Branches are cheap and github makes it easy to merge and delete branches with a few clicks. Avoid the temptation to lump in a bunch of unrelated changes when working on a feature, if possible. This helps us keep track of what has changed when preparing a release.
-- Commit messages should be clear and concise. This means a subject line of less than 80 characters, and, if necessary, a blank line followed by a commit message body. We have an `informal commit format standard <http://www.statsmodels.org/devel/dev/maintainer_notes.html#commit-comments>`_ that we try to adhere to. You can see what this looks like in practice by ``git log --oneline -n 10``. If your commit references or closes a specific issue, you can close it by mentioning it in the `commit message <https://help.github.com/articles/closing-issues-via-commit-messages>`_.  (*For maintainers*: These suggestions go for Merge commit comments too. These are partially the record for release notes.)
-- Code submissions must always include tests. See our `notes on testing <http://www.statsmodels.org/devel/dev/test_notes.html>`_.
+- Commit messages should be clear and concise. This means a subject line of less than 80 characters, and, if necessary, a blank line followed by a commit message body. We have an `informal commit format standard <https://www.statsmodels.org/devel/dev/maintainer_notes.html#commit-comments>`_ that we try to adhere to. You can see what this looks like in practice by ``git log --oneline -n 10``. If your commit references or closes a specific issue, you can close it by mentioning it in the `commit message <https://help.github.com/articles/closing-issues-via-commit-messages>`_.  (*For maintainers*: These suggestions go for Merge commit comments too. These are partially the record for release notes.)
+- Code submissions must always include tests. See our `notes on testing <https://www.statsmodels.org/devel/dev/test_notes.html>`_.
 - Each function, class, method, and attribute needs to be documented using docstrings. We conform to the `numpy docstring standard <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard>`_.
 - If you are adding new functionality, you need to add it to the documentation by editing (or creating) the appropriate file in ``docs/source``.
 - Make sure your documentation changes parse correctly. Change into the top-level ``docs/`` directory and type::
@@ -41,7 +41,7 @@ So you want to submit a patch to `statsmodels` but aren't too familiar with gith
 2. `Create a new feature branch <http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging>`_. Each branch must be self-contained, with a single new feature or bugfix. 
 3. Make sure the test suite passes. This includes testing on Python 3. The easiest way to do this is to either enable `Travis-CI <https://travis-ci.org/>`_ on your fork, or to make a pull request and check there.
 4. Document your changes by editing the appropriate file in ``docs/source/``. If it is a big, new feature add a note and an example to the latest ``docs/source/release/versionX.X.rst`` file. See older versions for examples. If it's a minor change, it will be included automatically in our relase notes.
-5. Add an example. If it is a big, new feature please submit an example notebook by following `these instructions <http://www.statsmodels.org/devel/dev/examples.html>`_.
+5. Add an example. If it is a big, new feature please submit an example notebook by following `these instructions <https://www.statsmodels.org/devel/dev/examples.html>`_.
 6. `Submit a pull request <https://help.github.com/articles/using-pull-requests>`_ 
 
 Mailing List
@@ -52,7 +52,7 @@ Conversations about development take place on the `statsmodels mailing list <htt
 Learn More
 ~~~~~~~~~~
 
-The ``statsmodels`` documentation's `developer page <http://www.statsmodels.org/stable/dev/index.html>`_
+The ``statsmodels`` documentation's `developer page <https://www.statsmodels.org/stable/dev/index.html>`_
 offers much more detailed information about the process.
 
 License

INSTALL.txt

@@ -111,7 +111,7 @@ You will need a C compiler installed.
 Installing from Source on Windows
 ---------------------------------
 
-See http://www.statsmodels.org/devel/install.html#windows.
+See https://www.statsmodels.org/devel/install.html#windows.
 
 
 Documentation
@@ -120,4 +120,4 @@ Documentation
 You may find more information about the project and installation in our 
 documentation
 
-http://www.statsmodels.org/devel/install.html
+https://www.statsmodels.org/devel/install.html

README.rst

@@ -13,18 +13,18 @@ Documentation
 
 The documentation for the latest release is at
 
-http://www.statsmodels.org/stable/
+https://www.statsmodels.org/stable/
 
 The documentation for the development version is at
 
-http://www.statsmodels.org/dev/
+https://www.statsmodels.org/dev/
 
 Recent improvements are highlighted in the release notes
 
-http://www.statsmodels.org/stable/release/version0.9.html
+https://www.statsmodels.org/stable/release/version0.9.html
 
-Backups of documentation are available at http://statsmodels.github.io/stable/
-and http://statsmodels.github.io/dev/.
+Backups of documentation are available at https://statsmodels.github.io/stable/
+and https://statsmodels.github.io/dev/.
 
 
 
@@ -125,7 +125,7 @@ https://github.com/statsmodels/statsmodels/tags
 
 Binaries and source distributions are available from PyPi
 
-http://pypi.python.org/pypi/statsmodels/
+https://pypi.org/project/statsmodels/
 
 Binaries can be installed in Anaconda
 
@@ -137,7 +137,7 @@ Installing from sources
 
 See INSTALL.txt for requirements or see the documentation
 
-http://statsmodels.github.io/dev/install.html
+https://statsmodels.github.io/dev/install.html
 
 License
 =======

docs/source/about.rst

@@ -57,7 +57,7 @@ development of statsmodels:
 
 We would also like to thank our hosting providers, `github
 <https://github.com/>`_ for the public code repository, `github.io
-<http://www.statsmodels.org/stable/index.html>`_ for hosting our documentation and `python.org
+<https://www.statsmodels.org/stable/index.html>`_ for hosting our documentation and `python.org
 <https://www.python.org/>`_ for making our downloads available on PyPi.
 
 We also thank our continuous integration providers,

docs/source/conf.py

@@ -301,12 +301,12 @@
 
 # Example configuration for intersphinx: refer to the Python standard library.
 intersphinx_mapping = {
-        'numpy' : ('https://docs.scipy.org/doc/numpy/', None),
-        'python' : ('https://docs.python.org/3.2', None),
-        'pydagogue' : ('http://matthew-brett.github.io/pydagogue/', None),
-        'patsy' : ('http://patsy.readthedocs.io/en/latest/', None),
-        'pandas' : ('http://pandas.pydata.org/pandas-docs/stable/', None),
-        }
+    'numpy': ('https://docs.scipy.org/doc/numpy/', None),
+    'python': ('https://docs.python.org/3/', None),
+    'pydagogue': ('https://matthew-brett.github.io/pydagogue/', None),
+    'patsy': ('https://patsy.readthedocs.io/en/latest/', None),
+    'pandas': ('https://pandas.pydata.org/pandas-docs/stable/', None),
+}
 
 from os.path import dirname, abspath, join
 plot_basedir = join(dirname(dirname(os.path.abspath(__file__))), 'source')

docs/source/datasets/index.rst

@@ -25,7 +25,7 @@ Using Datasets from Stata
 Using Datasets from R
 ---------------------
 
-The `Rdatasets project <http://vincentarelbundock.github.io/Rdatasets/>`__ gives access to the datasets available in R's core datasets package and many other common R packages. All of these datasets are available to statsmodels by using the :func:`get_rdataset` function. The actual data is accessible by the ``data`` attribute. For example:
+The `Rdatasets project <https://vincentarelbundock.github.io/Rdatasets/>`__ gives access to the datasets available in R's core datasets package and many other common R packages. All of these datasets are available to statsmodels by using the :func:`get_rdataset` function. The actual data is accessible by the ``data`` attribute. For example:
 
 .. ipython:: python
 

docs/source/dev/examples.rst

@@ -26,7 +26,7 @@ Examples are best contributed as IPython notebooks. Save your notebook with all
 The Example Gallery
 ~~~~~~~~~~~~~~~~~~~
 
-We have a gallery of example notebooks available `here <http://www.statsmodels.org/devel/examples/index.html>`_. If you would like your example to show up in this gallery, add a link to the notebook in ``docs/source/examples/landing.json``. For the thumbnail, take a screenshot of what you think is the best "hook" for the notebook. The image will be displayed at 360 x 225 (W x H). It's best to save the image as a PNG with a resolution that is some multiple of 360 x 225 (720 x 450 is preferred).
+We have a gallery of example notebooks available `here <https://www.statsmodels.org/devel/examples/index.html>`_. If you would like your example to show up in this gallery, add a link to the notebook in ``docs/source/examples/landing.json``. For the thumbnail, take a screenshot of what you think is the best "hook" for the notebook. The image will be displayed at 360 x 225 (W x H). It's best to save the image as a PNG with a resolution that is some multiple of 360 x 225 (720 x 450 is preferred).
 
 
 Before submitting a PR

docs/source/dev/index.rst

@@ -21,7 +21,7 @@ Making Changes to the Code
 For a pull request to be accepted, you must meet the below requirements. This greatly helps the job of maintaining and releasing the software a shared effort.
 
 - **One branch. One feature.** Branches are cheap and github makes it easy to merge and delete branches with a few clicks. Avoid the temptation to lump in a bunch of unrelated changes when working on a feature, if possible. This helps us keep track of what has changed when preparing a release.
-- Commit messages should be clear and concise. This means a subject line of less than 80 characters, and, if necessary, a blank line followed by a commit message body. We have an `informal commit format standard <http://www.statsmodels.org/devel/dev/maintainer_notes.html#commit-comments>`_ that we try to adhere to. You can see what this looks like in practice by ``git log --oneline -n 10``. If your commit references or closes a specific issue, you can close it by mentioning it in the `commit message <https://help.github.com/articles/closing-issues-via-commit-messages/>`_.  (*For maintainers*: These suggestions go for Merge commit comments too. These are partially the record for release notes.)
+- Commit messages should be clear and concise. This means a subject line of less than 80 characters, and, if necessary, a blank line followed by a commit message body. We have an `informal commit format standard <https://www.statsmodels.org/devel/dev/maintainer_notes.html#commit-comments>`_ that we try to adhere to. You can see what this looks like in practice by ``git log --oneline -n 10``. If your commit references or closes a specific issue, you can close it by mentioning it in the `commit message <https://help.github.com/articles/closing-issues-via-commit-messages/>`_.  (*For maintainers*: These suggestions go for Merge commit comments too. These are partially the record for release notes.)
 - Code submissions must always include tests. See our notes on :ref:`testing`.
 - Each function, class, method, and attribute needs to be documented using docstrings. We conform to the `numpy docstring standard <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#docstring-standard>`_.
 - If you are adding new functionality, you need to add it to the documentation by editing (or creating) the appropriate file in ``docs/source``.