New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update cachecontrol from 0.11.1 to 0.11.2 #2595

Merged
merged 1 commit into from Mar 22, 2015

Conversation

Projects
None yet
2 participants
@msabramo
Contributor

msabramo commented Mar 21, 2015

Fixes #2481

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2015

Member

Can you add a changelog entry with the fact we updated the version and what pip bug(s) it fixes?

Member

dstufft commented Mar 21, 2015

Can you add a changelog entry with the fact we updated the version and what pip bug(s) it fixes?

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 21, 2015

Contributor

Hmmm, this needs to be munged to use pip/_vendor for requests, lockfile, etc. Do you have a script for that?

Contributor

msabramo commented Mar 21, 2015

Hmmm, this needs to be munged to use pip/_vendor for requests, lockfile, etc. Do you have a script for that?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2015

Member

Nope, I just do it by hand.

Member

dstufft commented Mar 21, 2015

Nope, I just do it by hand.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 21, 2015

Contributor

Ok, I'm AFK so I can update l8r.

I wonder if we could modify pip so that it adds the pip._vendor directory to the front of sys.path and then maybe the munging wouldn't be necessary?

Contributor

msabramo commented Mar 21, 2015

Ok, I'm AFK so I can update l8r.

I wonder if we could modify pip so that it adds the pip._vendor directory to the front of sys.path and then maybe the munging wouldn't be necessary?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2015

Member

When we started bundling we didn't want to do that originally because even though we don't support using pip as a library, some people do use it that way and we didn't want to pollute the sys.path.

Member

dstufft commented Mar 21, 2015

When we started bundling we didn't want to do that originally because even though we don't support using pip as a library, some people do use it that way and we didn't want to pollute the sys.path.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 21, 2015

Contributor

Ah makes sense but maybe just do it if __name__ == '__main__'?

Contributor

msabramo commented Mar 21, 2015

Ah makes sense but maybe just do it if __name__ == '__main__'?

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 21, 2015

Contributor

And/or make it something that can be turned off with command line option or environment variable -- that could make it easier to test with newer versions of packages by pulling from system instead of _vendor

Contributor

msabramo commented Mar 21, 2015

And/or make it something that can be turned off with command line option or environment variable -- that could make it easier to test with newer versions of packages by pulling from system instead of _vendor

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2015

Member

I think that just importing from pip._vendor is less error prone, modifying the imports whenever we upgrade isn't that big of a deal to me.

Member

dstufft commented Mar 21, 2015

I think that just importing from pip._vendor is less error prone, modifying the imports whenever we upgrade isn't that big of a deal to me.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 21, 2015

Contributor

Ok that's cool too.

Contributor

msabramo commented Mar 21, 2015

Ok that's cool too.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 22, 2015

Contributor

Rebased.

Contributor

msabramo commented Mar 22, 2015

Rebased.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 22, 2015

Contributor

Looking good, @dstufft?

Contributor

msabramo commented Mar 22, 2015

Looking good, @dstufft?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 22, 2015

Member

It looks fine to me, I'm waiting for the tests to finish.

Member

dstufft commented Mar 22, 2015

It looks fine to me, I'm waiting for the tests to finish.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 22, 2015

Contributor

It looked like just py26 is going to fail so probably Travis networking silliness.

Contributor

msabramo commented Mar 22, 2015

It looked like just py26 is going to fail so probably Travis networking silliness.

@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 22, 2015

Contributor

Although I guess we need to make sure it's not that cachecontrol broke 2.6 compat which would be bad.

Contributor

msabramo commented Mar 22, 2015

Although I guess we need to make sure it's not that cachecontrol broke 2.6 compat which would be bad.

dstufft added a commit that referenced this pull request Mar 22, 2015

@dstufft dstufft merged commit 707e889 into pypa:develop Mar 22, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@msabramo

This comment has been minimized.

Show comment
Hide comment
@msabramo

msabramo Mar 22, 2015

Contributor

Oh weird it passed. I must've looked at wrong Travis page

Contributor

msabramo commented Mar 22, 2015

Oh weird it passed. I must've looked at wrong Travis page

@msabramo msabramo deleted the msabramo:updated_cachecontrol_to_0.11.2 branch Mar 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment