-
Notifications
You must be signed in to change notification settings - Fork 62
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
feat: new ctl #395
feat: new ctl #395
Conversation
e2d2841
to
bbda5a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just some minor things. Lets get this merged and released! 🚀
@hugomrdias are you going to polish off the last few nits in this? It'd be good to get it in to unblock a bunch of other stuff. |
🙏 pretty please can we have this? |
@alanshaw +1 |
PR description updated explaining whats new and whats changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nits, looks good though
README.md
Outdated
### Remote endpoint - `const server = IPFSFactory.createServer([options])` | ||
|
||
`IPFSFactory.createServer` starts a IPFSFactory endpoint. | ||
### `create([options])` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be better named createFactory([options])
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
damn it was like that i just changed it back yesterday to reduce the diff for the end user.
do you think it's worth it ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good to be explicit. The diff is going to be hefty anyway, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the top level api nothing actually changed just the options are different
*/ | ||
start () { | ||
console.warn('Server not implemented in the browser') | ||
return Promise.resolve(this) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this (and the other methods in this class) throw instead?
README.md
Outdated
@@ -58,11 +58,11 @@ await ipfsd.stop() | |||
// Start a remote disposable node, and get access to the api | |||
// print the node id, and stop the temporary daemon | |||
|
|||
const IPFSFactory = require('ipfsd-ctl') | |||
const { create, createServer } = require('ipfsd-ctl') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the previous require style, using create()
in code makes me think "what am I creating?" whereas IPFSFactory.create()
is obvious.
README.md
Outdated
|
||
console.log('endpoint has stopped') | ||
``` | ||
### `createNodeTests([options])` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just createNode({ test: true })
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i can do that sure
README.md
Outdated
#### TestsInterface | ||
`nodes` **Array** List of the created controlled nodes. | ||
`node()` **Function** Creates a standalone node, this node will **NOT** be stopped by `teardown()`. | ||
`setup(options)` **Function(**[FactoryOptions](#FactoryOptions)**)** Creates a controlled node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "controlled" mean? Just that they get stopped when teardown
is called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
README.md
Outdated
Returns a **[TestsInterface](#TestsInterface)** | ||
#### TestsInterface | ||
`nodes` **Array** List of the created controlled nodes. | ||
`node()` **Function** Creates a standalone node, this node will **NOT** be stopped by `teardown()`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about just using the same API but providing an option? setup({ controlled: false })
? setup({ managed: false })
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs better wording
node()
returns the a ctl node
setup()
returns directly an ipfs core api
Should both return the same thing ?
i would rather add a new param than to use an option just to keep FactoryOptions
clean. Cause this would be specific to the testInterface.
I also think using the word node
here is wrong... We use daemon for process nodes and node for in process etc... but here it's actually a Controller
for a IPFS node either process or in-proc.
Would you agree if i change the naming to Controller
instead of Node
?
Then ipfsd-ctl would have:
Factory
to wrap spawn, version and tmpDir
Controller
to wrap the 3 different types of node
plus some methods that return an IPFS Core API.
README.md
Outdated
|
||
Get the address (multiaddr) of connected IPFS HTTP Gateway. Returns a multiaddr. | ||
### `createServer([options])` | ||
Create an Endpoint Server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs elaboration! What is the server for? Why would you create one? What can it do?
README.md
Outdated
- proc - spawn in-process js-ipfs instance | ||
- `env` **[Object]** Additional environment variables, passed to executing shell. Only applies for Daemon controllers. | ||
- `args` **[Array]** Custom cli args. | ||
- `ipfsHttp` **[Object]** Setup IPFS HTTP client to be used by ctl. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I pass this option are the properties both mandatory? Please can the documentation be clarified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nothing is mandatory, but if you really want to make sure you are using a specific version you need to specify both!
ill update the readme with that info !
README.md
Outdated
- `ipfsHttp` **[Object]** Setup IPFS HTTP client to be used by ctl. | ||
- `ipfsHttp.ref` **[Object]** Reference to a IPFS HTTP Client object. (defaults to the local require(`ipfs-http-client`)) | ||
- `ipfsHttp.path` **[string]** Path to a IPFS HTTP Client to be required. (defaults to the local require.resolve('ipfs-http-client')) | ||
- `ipfsApi` **[Object]** Setup IPFS API to be used by ctl. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced this is the best name for this...especially considering IPFS HTTP Client used to be called ipfs-api
and both js-ipfs
and js-ipfs-http-client
expose the same API.
What about ipfsModule
and ipfsHttpClientModule
for these?
README.md
Outdated
- `ipfsApi.ref` **[Object]** Reference to a IPFS API object. (defaults to the local require(`ipfs`)) | ||
- `ipfsApi.path` **[string]** Path to a IPFS API implementation to be required. (defaults to the local require.resolve('ipfs')) | ||
- `ipfsBin` **[string]** Path to a IPFS exectutable . (defaults to the local 'js-ipfs/src/bin/cli.js') | ||
- `ipfsOptions` **[IpfsOptions]** Options for the IPFS instance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify when these are applicable? I assume they do not work for HTTP client or go daemon?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they work for all 3 types as far as possible exactly like the old version.
proc
its passed directlydaemon
it translates as much as possible to args (plus you can manually define and extraargs
option)client
same as daemon cause its just a proxy
this change was to normalise and have just one set possible of options
README.md
Outdated
|
||
const server = IPFSFactory.createServer({ port: 12345 }) | ||
### `createNode([options])` | ||
Creates a node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why you'd use createNode
and not create
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
create
creates a factory and you get .tmpDir()
, .version()
and .spawn()
createNode
return the node directly basically calls spawn()
for you which is what you want 90% of the time.
i didn't made createNode
default because there are some use cases that you really need Factory.tmpDir()
to create a temp dir for the repo when using a remote node.
Moved a few things around to integrate your feedback. Please review again. |
|
||
Get the version without spawning a daemon | ||
### `createServer([options])` | ||
Create an Endpoint Server. This server is used by a client node to control a remote node. Example: Spawning a go-ipfs node from a browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any docs for the API endpoints that are available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, its mostly to be used by the remote Controller
not for public use.
we supported ['--pass some-string'] which is not very common in any process spawning lib so now we only support the common syntax which is ['--pass', 'some-string']
Co-Authored-By: Alex Potsides <[email protected]>
a04b555
to
982bb12
Compare
Adds interface-core common tests setup to ipfsd-ctl so we can dedupe this code from js-ipfs (https://github.com/ipfs/js-ipfs/blob/master/test/utils/interface-common-factory.js#L71) and http-client (https://github.com/ipfs/js-ipfs-http-client/blob/master/test/utils/interface-common-factory.js).
Also adds jsdocs to be easier to transition to this new async setup.
It works basically the same as the
createAsync
version with one less function call and a new method to create an unmanaged node to be used inside tests you want to stop manually.PRs to use this in js-ipfs, http-client and interface-core will follow
This PR evolved from adding some helper functions for tests into a full rewrite (sorry about that 😅). While making the supporting PRs i found some problems and inconsistencies that needed to be fix to improve our own and contributors DX.
Problems:
Related issues:
Improvements:
stop()
New:
createController
returns a spawned controllerChanges:
create
change tocreateFactory
createFactory
options changedOld
New
test
options equalstrue
defaultAddrs
option was removedcreateFactory
Old
NEW
Same as js-ipfs constructor https://github.com/ipfs/js-ipfs#ipfs-constructor
TODO: