Remove py-libp2p-daemon
See original GitHub issuepypi rejects releases with this kind of dependency:
https://github.com/libp2p/py-libp2p/blob/811cd7813a74ef55110e1ae09dac7028c6caa0a4/setup.py#L12-L13
I had to manually remove that line from the tagged commit before releasing.
Some options:
- remove it (maybe it’s cruft that is not necessary anymore?)
- inline it (maybe it’s small enough that it’s worth just bringing into this repo)
- do a proper release of
py-libp2p-daemon
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top Results From Across the Web
libp2p Daemon - GitHub
A standalone deployment of a libp2p host, running in its own OS process and installing a set of virtual endpoints to enable co-local...
Read more >libp2p-daemon-client - npm
A Javascript client to interact with a standalone deployment of a libp2p host, running in its own OS process. Essentially, this client ...
Read more >Python IPFS API Documentation - Read the Docs
A TCP client for interacting with an IPFS daemon. ... Parameters key (str) – Key to remove from wantlist. 1.1. Client API Reference....
Read more >Guide to IPFS garbage collection - LogRocket Blog
Improve the speed and efficiency of your IPFS application with garbage collection, removing unwanted, empty resources over a network.
Read more >Client API Reference — Python IPFS API 0.4.1 documentation
Raised when daemon version is not supported by this client version. exception ipfsapi.exceptions. ... Parameters: key (str) – Key to remove from wantlist....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
just to chime in here, i think having
py-libp2p
be the “foundational” package here (possibly used byp2pclient
) makes the most sense – while the extent to which we make affordances tolibp2p
towards this end is subjective, i’d think its worthwhile exploring the interop tests to see if we can’t accomplish them another way – for example, a full interop suite would also involverust-libp2p
,nim-libp2p
andjs-libp2p
alongsidego-libp2p
where we won’t have client bindings (easily)I think the best solution then might be to only install
p2pclient
in the specific tox environment that runs these integration tests, something like:tox.ini