[WIP] Fix up appveyor testing.

This PR will track work as I try to work out where the hell `make` is on appveyor.

Ok, some progress has been made. We are now getting build failures due to our dependencies.

Python 2.6 is failing because of click, presumably because click doesn't support Python 2.6 + Windows:

```
pipenv lock
Traceback (most recent call last):
  File "c:\python266-x64\lib\runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python266-x64\lib\runpy.py", line 34, in _run_code
    exec code in run_globals
  File "C:\Python266-x64\Scripts\pipenv.exe\__main__.py", line 5, in <module>
  File "c:\python266-x64\lib\site-packages\pipenv\__init__.py", line 14, in <module>
    from .cli import cli
  File "c:\python266-x64\lib\site-packages\pipenv\cli.py", line 11, in <module>
    import click
  File "c:\python266-x64\lib\site-packages\pipenv\vendor\click\__init__.py", line 18, in <module>
    from .core import Context, BaseCommand, Command, MultiCommand, Group, \
  File "c:\python266-x64\lib\site-packages\pipenv\vendor\click\core.py", line 8, in <module>
    from .types import convert_type, IntRange, BOOL
  File "c:\python266-x64\lib\site-packages\pipenv\vendor\click\types.py", line 4, in <module>
    from ._compat import open_stream, text_type, filename_to_ui, \
  File "c:\python266-x64\lib\site-packages\pipenv\vendor\click\_compat.py", line 536, in <module>
    from ._winconsole import _get_windows_console_stream
  File "c:\python266-x64\lib\site-packages\pipenv\vendor\click\_winconsole.py", line 19, in <module>
    from ctypes import byref, POINTER, c_int, c_char, c_char_p, \
ImportError: cannot import name c_ssize_t
```

Python 2.7 and later are failing at install time:

```
pipenv lock
Creating a virtualenv for this project...
Warning! If you are running on Windows, you should use the --python option instead.
Using base prefix 'c:\\python33-x64'
New python executable in C:\Users\appveyor\.virtualenvs\requests-hjhYtdkP\Scripts\python.exe
Installing setuptools, pip, wheel...done.
Virtualenv location: C:\Users\appveyor\.virtualenvs\requests-hjhYtdkP
Locking [dev-packages] dependencies...
Traceback (most recent call last):
  File "c:\python33-x64\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python33-x64\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Python33-x64\Scripts\pipenv.exe\__main__.py", line 9, in <module>
  File "c:\python33-x64\lib\site-packages\pipenv\vendor\click\core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "c:\python33-x64\lib\site-packages\pipenv\vendor\click\core.py", line 697, in main
    rv = self.invoke(ctx)
  File "c:\python33-x64\lib\site-packages\pipenv\vendor\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\python33-x64\lib\site-packages\pipenv\vendor\click\core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\python33-x64\lib\site-packages\pipenv\vendor\click\core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "c:\python33-x64\lib\site-packages\pipenv\cli.py", line 893, in lock
    do_lock(no_hashes=no_hashes)
  File "c:\python33-x64\lib\site-packages\pipenv\cli.py", line 440, in do_lock
    results = get_downloads_info(names_map, 'dev-packages')
  File "c:\python33-x64\lib\site-packages\pipenv\cli.py", line 405, in get_downloads_info
    name = list(convert_deps_from_pip(names_map[fname]))[0]
KeyError: 'Babel-2.4.0-py2.py3-none-any.whl'
```

My *suspicion* here is that this is pipenv related. @nateprewitt, any insights into what's happening there?

As to the Python 2.6 thing, how severe that is is unclear. We technically count 2.6 as a supported platform, so it's pretty ungraceful that you can't run our tests on it. On the other hand, pipenv doesn't support Python 2.6 on Windows (because, transitively, click doesn't), so maybe that's just not a surprise?

# [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=h1) Report
> Merging [#3988](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=desc) into [master](https://codecov.io/gh/kennethreitz/requests/commit/84099eea9f99168b73ff48270dcab24e5a1ee959?src=pr&el=desc) will **increase** coverage by `0.04%`.
> The diff coverage is `100%`.

[![Impacted file tree graph](https://codecov.io/gh/kennethreitz/requests/pull/3988/graphs/tree.svg?token=mZGswIiXLa&src=pr&height=150&width=650)](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master    #3988      +/-   ##
==========================================
+ Coverage   89.72%   89.76%   +0.04%     
==========================================
  Files          15       15              
  Lines        1946     1955       +9     
==========================================
+ Hits         1746     1755       +9     
  Misses        200      200
```


| [Impacted Files](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/sessions.py](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `93.95% <100%> (+0.2%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=footer). Last update [84099ee...fcc3b7d](https://codecov.io/gh/kennethreitz/requests/pull/3988?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@Lukasa yep, that's definitely something wrong in Pipenv. I'm unsure if it's a transient issue or something more. Can we kick the build? I don't seem to have permissions on appveyor, or perhaps it doesn't have an option to rebuild the test.

Yup, this is a duplicate of kennethreitz/pipenv#213. @nateprewitt, on that issue you said you wanted a repro environment: I think I got you one. ;)

@nateprewitt The easiest thing to do, honestly, if @kennethreitz doesn't mind too much, is to just open a new PR and push to it repeatedly to kick off builds. That'll hopefully allow you to play around and work out what's happening.

Failing that, I think you'd either have to spin up a cloud Windows machine or wait for about an hour for me to get to my local Windows box.

Aha! Good catch, I'll spin up appveyor for pipenv after lunch and try to get that pinned down.

@nateprewitt You may not be able to enable it for pipenv: we needed Kenneth to do it for Requests. 

@lukasa I have 2.7 running tests on Windows now (although they're failing on Socks support) with a patched branch of pipenv. It's a casing conflict for file names. I think we can get that fix rolled out pretty quickly.

The click issue seems to be noted in pallets/click#735 but hasn't received any response. Not sure if they have any intent to support 2.6 in this environment.

Ok cool, I'll strip 2.6 support when the pipenv fix lands.

Alright @Lukasa, sorry for the delay. I've cut 3.6.0 for pipenv, so this issue should be fixed if you want to rebase or push another commit.

There are a few more errors when you get past the pipenv failure that I haven't had time to fully investigate. From a cursory glance though, this is what I've found so far.

 * 2.6 needs to be removed from the test list for appveyor.
 * `win_inet_pton` appears to be a requirement for PySocks to run in Python 2.X on Windows.
 * The `test_time_elapsed_blank` was failing with what appeared to be a division rounding issue, but my latest builds this morning aren't producing this. Something to keep an eye out for though.

Thanks @nateprewitt, I'll start working through that stuff now. =)

Hey look, this is why we should be testing on Windows! It seems that `elapsed` doesn't work as expected on Windows, because `datetime.datetime.utcnow` has a pretty low resolution, meaning that sufficiently fast requests may be labelled as taking zero time.

I believe this will work more sensibly if we use a different function to build the timedelta object.

Hrm. Sadly, using `time.time()` also doesn't fix the problem on Windows: the two timestamps remain the same. I think it's possible that we cannot get an appropriately accurate clock on a Windows machine for this test to run as expected.

So, on Windows, we need to use `time.clock` to get the accurate timestamps we want. In this case, we probably need to use `time.time` and `time.clock` to get the accuracy we want, and then create the `timedelta` ourselves. Should be easy enough.

Probably shouldn't rely on `time.clock` as it's been [deprecated](https://docs.python.org/3/library/time.html#time.clock) since 3.3.
Is it valid to use `time.perf_counter` when available in this context?

Oh god, who knows? I guess, based on the reading of that documentation, the answer is yes?

Hrm, these clock changes do not appear to be helping. I wonder what that's about.

Uh...awkward. Let's not talk about what I got wrong there.

@nateprewitt Is it possible to declare a conditional dependency in a Pipfile?

@Lukasa I was thinking about that last week with the pton dependency requirement. We don't currently have a way to handle something like that, but from what I can tell neither does pip without conditional code in setup.py.

Perhaps we define the list used for `socks` in `extras_require` earlier and then append `win_inet_pton`  if `platform.system()` is Windows? That should work consistently for users without any syntax changes, and pipenv already uses `extras_requires` from setup.py.

I think pip can do it fine with markers. I tried to add something in 63e5b80a6b1b386f9f43ac07948306d0fa2d333b but have yet to test it live: will do so shortly. @dstufft, am I right in assuming that I can add a marker that says "if you do `pip install requests[socks]` on Windows, install this other dependency?"

@nateprewitt Adding dependencies in code in `setup.py` is almost always a bad idea, because wheels don't execute `setup.py`. That means whether or not users get the Windows dependency boils down to the system on which the wheel was built: that is, if I build the wheel on my Mac then no-one gets the Windows dep, while if I build it on my Windows box *everyone* does. That's not really a winning strategy. =)

@Lukasa 😬 I'm glad you're here to vet my advice. So the marker is evaluated at install time even for wheels? Good to know!

@Lukasa, sorry I should have had my coffee before replying to this. This is probably what you were referencing in your original question, but we aren't installing anything from setup.py in the current Makefile.

Since we can't declare a conditional dependency in Pipfile, this will either need to be handled in the Makefile or appveyor.yml, rather than setup.py. It seems pretty kludgy to shove the conditional into `init`, but `make` should give you what you need to run the test suite. appveyor.yml would fix the testing on our end, but probably result in tickets complaining about tests not working locally on Windows.

Hrm.

Well, in the first instance we should consider this a feature request for conditional dependencies in Pipfile. I've used them a bit in Python, they're a fairly useful feature, so Pipfile should probably aim to support it at some point. :wink:

Doing this in the Makefile is gonna suck, so for now we'll do it in appveyor.yml.

Hrm, it looks a lot like appveyor isn't reporting coverage. I wonder why that is.

What happens if we just run `codecov`? I don't know much about `pipenv`.

We need to run it via `pipenv`, that will automatically use the virtualenv in which codecov is installed.

*Realizing I should probably read more on `pipenv`*
:thinking::thought_balloon: 

There we go, that appeared to work. Ok, so let's not merge this yet: I want to confirm with @dstufft that the marker I put in place here actually, you know, works.