Add README to requests/packages

- Hopefully people will read this before making changes to vendored libraries

Hopefully this will prevent PRs like: #1773


I approve this message. I don't approve the fact that Travis CI tested it instead of Jenkins.


@kennethreitz can you turn off the Travis integration hook altogether? This is annoying. I'd be willing to guess that they both ran this but Travis ran it last and got precendence over the other.


uh, i thought i did. grumble.


I'm not sure what's going on. I disabled the WebHook and no longer have a Travis CI account.


> I'm not sure what's going on. I disabled the WebHook and no longer have a Travis CI account.

Go to Settings (upper right corner) > Applications and disable the one for Travis. That will deny them the privilege to write to any of your repos. I'm not entirely certain applications can request GitHub delete the authorization tokens they were granted by the user.


Ah, good call! Now, to find out why our own tests aren't being reported for some reason.


I develop and maintain an API wrapper, I _should_ know these things ;)

As for why Jenkins isn't getting reported, check the webhooks for the post-receive that sends the hook data to it, then check to make sure you have an authorization in the same section for it. If necessary, delete your existing one and make a new one. I don't know what else could have happened with that though. Let me also take a look at the commit status API returns for these PRs to see if Jenkins is getting reported and not just overtaken by Travis.


I enabled two-factor auth for work recently. Might be related.

The tests are being run, just not being reported back properly. I suspect your theory may be correct.


Two-Factor Auth might invalidate old tokens but really _shouldn't_. That also only effects it if Jenkins is using Basic Authentication to access the API. If it is, then that is most certainly the issue. If you made a token however, then that's really bizarre and should be mentioned to the API team via the contact form. We could also just ping @izuzak here ;)


I suspect travis interference :)


Well there are absolutely _no statuses_ on that commit according to the API... that's just weird.


FWIW:

``` python
import github3

requests = github3.repository('kennethreitz', 'requests')
pull = requests.pull_request(1775)
commit = next(pull.iter_commits())
statuses = list(requests.iter_statuses(commit.sha))  # => []
```


I know why Travis ran on this PR. I had set up Travis to run on my branch too so I could check stuff _before_ submitting a PR. Somehow that must be bleeding over here especially since I have commit privileges. That's extraordinarily bizarre but it make sense since it only seemed to happen on my PR and not on others (unless I missed them). 

Turning off now.


@sigmavirus24 you're more than welcome to work in the main repo in side-branches :)


> We could also just ping @izuzak here ;)

Pong! Just wanted to drop a note about those statuses. Notice the difference when you request statuses for the commit in the context of sigmavirus24/requests:

https://api.github.com/repos/sigmavirus24/requests/statuses/617bc8cc1c1b34b11954cf9e4caec3a25a07167b

and in the context of kennethreitz/requests

https://api.github.com/repos/kennethreitz/requests/statuses/617bc8cc1c1b34b11954cf9e4caec3a25a07167b

So, statuses were set by Travis, but just for sigmavirus24/requests (and not for kennethreitz/requests), which was expected, right?

Also, as far as I know, turning on 2FA should not invalidate existing OAuth tokens. [Let us know](https://github.com/contact) if you suspect that indeed did happen.