Temporarily install ipfshttpclient from master branch

[ibnesayeed]

A recent change in the IPFS API removed support for GET/HEAD methods on some endpoints. This prevents us from upgrading to go-ipfs-v0.5.0 as per #638. Corresponding change in the ipfshttpclient is added to the master branch, but not released on PyPI yet. This is a temporary fix, but once the updated package is out, we should update the dependency.

Since this is a temporary fix, I am not changing the dependency in the setup.py file. Should I?

[codecov]

Codecov Report

Merging #641 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #641   +/-   ##
=======================================
  Coverage   27.28%   27.28%           
=======================================
  Files           7        7           
  Lines        1246     1246           
  Branches      191      191           
=======================================
  Hits          340      340           
  Misses        881      881           
  Partials       25       25           

Impacted Files	Coverage Δ
setup.py	0.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4adb8bd...070ef18. Read the comment docs.

[ibnesayeed]

I made changes in the setup.py file as well, but now it is complaining about lne too long, thought I would not like to break URL to pass the linter.

[ibnesayeed]

Thanks for this @machawk1, yesterday I was looking for annotations to add exception here, but I did not search well enough. From the brief look at the documentation I thought they have options to disable certain validations globally, but not per line exceptions.

[machawk1]

@ibnesayeed LGTM as a temp fix. I added a directive to the setup file in 070ef18 to allow the line to pass the linter. In an effort to stay current, should we push another release for compatibility's sake?

[ibnesayeed]

In an effort to stay current, should we push another release for compatibility's sake?

Let's wait for the new release of the ipfshttpclient before we push a new release. It is our primary dependency and I do not feel comfortable tagging a release that has non-frozen dependencies. Also, I am not too confident that PyPI will install the dependency properly when releasing there because there have been some changes in how dependencies are specified from a remote resource in the setup.py file. However, if the ipfshttpclient takes forever to release the new version, we may revisit our plan after a while.

[machawk1]

Ok, I agree, but the latest release of ipwb does not work with the latest release of go-ipfs currently. Do you want to revisit this in a few days, @ibnesayeed, and push a new ipwb release with a reference to the ipfshttpclient master if ipfshttpclient has not released a new version by then? Should we pin to an ipfshttpclient commit instead of simply master? Pinning to master seems dangerous and potentially breaking.

[ibnesayeed]

If we were to release in a few days, pinning to a hash will be safer, but not all intermediary references are fetchable from Git servers (a configuration for efficiency). We can perhaps ask the ipfshttpclient maintainer about their next release plan.

[machawk1]

@ibnesayeed Can you take the lead on the task you mentioned? Feel free to reference the relevant GitHub issues in the ipwb repo.

[ibnesayeed]

Can you take the lead on the task you mentioned?

Posted a comment at ipfs-shipyard/py-ipfs-http-client#204 (comment) to inquire about it.