Skip to content
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 usage of Python ipfsapi module to use its new name #608

Closed
machawk1 opened this issue May 27, 2019 · 5 comments · Fixed by #609
Closed

Update usage of Python ipfsapi module to use its new name #608

machawk1 opened this issue May 27, 2019 · 5 comments · Fixed by #609

Comments

@machawk1
Copy link
Member

machawk1 commented May 27, 2019

The Python version of the IPFSAPI has changed named from ipfsapi to ipfshttpclient. Attempting to run ipwb without parameters produces:

/usr/local/lib/python2.7/site-packages/ipwb/replay.py:15: FutureWarning: The `ipfsapi` library is deprecated and will stop receiving updates on the 31.12.2019! If you are on Python 3.5+ please enable and fix all Python deprecation warnings (CPython flag `-Wd`) and switch to the new `ipfshttpclient` library name. Python 2.7 and 3.4 will not be supported by the new library, so please upgrade.
  import ipfsapi

...which could probably be displayed through another means. Regardless, we should update ipwb to use the newer name for the API module.

@machawk1
Copy link
Member Author

Swapping out for the updated name (from 0b9bb3e) and running in Python 3 produces an error:

$ ipwb replay
Traceback (most recent call last):
  File "/usr/local/bin/ipwb", line 6, in <module>
    from ipwb.__main__ import main
  File "/usr/local/lib/python3.7/site-packages/ipwb/__main__.py", line 9, in <module>
    from . import replay
  File "/usr/local/lib/python3.7/site-packages/ipwb/replay.py", line 47, in <module>
    from . import indexer
  File "/usr/local/lib/python3.7/site-packages/ipwb/indexer.py", line 55, in <module>
    IPFS_API = ipfsapi.Client(IPFSAPI_HOST, IPFSAPI_PORT)
  File "/usr/local/lib/python3.7/site-packages/ipfshttpclient/client/base.py", line 120, in __init__
    self._client = self._clientfactory(addr, base, **defaults)
  File "/usr/local/lib/python3.7/site-packages/ipfshttpclient/http.py", line 168, in __init__
    addr = multiaddr.Multiaddr(addr)
  File "/usr/local/lib/python3.7/site-packages/multiaddr/multiaddr.py", line 126, in __init__
    self._bytes = string_to_bytes(addr)
  File "/usr/local/lib/python3.7/site-packages/multiaddr/transforms.py", line 17, in string_to_bytes
    for proto, codec, value in string_iter(string):
  File "/usr/local/lib/python3.7/site-packages/multiaddr/transforms.py", line 55, in string_iter
    raise exceptions.StringParseError("Must begin with /", string)
multiaddr.exceptions.StringParseError: Invalid MultiAddr 'localhost': Must begin with /

Perhaps there was a change in the underline multiaddr implementation that prevent ipwb from using localhost on the Client instantiation ipfsapi.Client(IPFSAPI_HOST, IPFSAPI_PORT) in replay.

@machawk1
Copy link
Member Author

A more fundamental example:

import ipfshttpclient
ipfshttpclient.Client('localhost', 9999)

produces the same result:

Traceback (most recent call last):
  File "ipfsclientest.py", line 3, in <module>
    ipfshttpclient.Client('localhost', 9999)
  File "/usr/local/lib/python3.7/site-packages/ipfshttpclient/client/base.py", line 120, in __init__
    self._client = self._clientfactory(addr, base, **defaults)
  File "/usr/local/lib/python3.7/site-packages/ipfshttpclient/http.py", line 168, in __init__
    addr = multiaddr.Multiaddr(addr)
  File "/usr/local/lib/python3.7/site-packages/multiaddr/multiaddr.py", line 126, in __init__
    self._bytes = string_to_bytes(addr)
  File "/usr/local/lib/python3.7/site-packages/multiaddr/transforms.py", line 17, in string_to_bytes
    for proto, codec, value in string_iter(string):
  File "/usr/local/lib/python3.7/site-packages/multiaddr/transforms.py", line 55, in string_iter
    raise exceptions.StringParseError("Must begin with /", string)
multiaddr.exceptions.StringParseError: Invalid MultiAddr 'localhost': Must begin with /

Though we are planning on decoupling ipwb from the expectation of an IPFS instance (#349), localhost has served as a sane default to get up-and-running. Some other loopback address might be appropriate to remedy the issue of accessing the local IPFS daemon, e.g., 0.0.0.0.

@ibnesayeed Your suggestion for an alternative to the above would be helpful here.

@machawk1 machawk1 changed the title Update ipfsapi to use its new name Update usage of Python ipfsapi module to use its new name May 27, 2019
@machawk1
Copy link
Member Author

machawk1 commented May 27, 2019

Ok, simply 0.0.0.0 won't work here, needs to be a multiaddr that starts with / per the error message.

Changes in Important changes from ipfsapi 0.4.x at https://github.com/ipfs/py-ipfs-api/ document this a little further:

The API deamon location is now described using MultiAddr, hence rather then doing ipfshttpclient.connect(host, port) to pass the network address parameters, use:
* ipfshttpclient.connect("/dns/<host>/tcp/<port>/http") (for hostnames such as localhost)
* ipfshttpclient.connect("/ip4/<IP-address>/tcp/<port>/http") (for IPv4 addresses)
* ipfshttpclient.connect("/ip6/<IP-address>/tcp/<port>/http") (for IPv6 addresses)
* Use …/https rather then …/http to connect to the API deamon using HTTPS

This will be somewhat key to #349. localhost or usage of hostnames will need to use dns whereas IP addresses will us the ipX-based multiaddress.

@machawk1
Copy link
Member Author

IPFS_API = ipfshttpclient.Client(f"/dns/{IPFSAPI_HOST}/tcp/{IPFSAPI_PORT}/http")

should work as a solution for now.

machawk1 added a commit that referenced this issue May 27, 2019
Fix client invocation per the new API module's docs.

Fixes #608
@ibnesayeed
Copy link
Member

That's a drastic change in the API. I hope they have a good reason to make such breaking changes.

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

Successfully merging a pull request may close this issue.

2 participants