In proc node config not applied

[alanshaw]

I'm trying to enable EXPERIMENTAL.dht for my in-proc node:

df.spawn({ config: { EXPERIMENTAL: { dht: true } } }, /* ... */)

The DHT experiment is not enabled because the in process node does not use the config property to configure the node, it expects EXPERIMENTAL to be in the root of the options object:

js-ipfsd-ctl/src/ipfsd-in-proc.js

Line 36 in cf794cd

this.opts.EXPERIMENTAL = defaults({}, opts.EXPERIMENTAL, {

[dryajov]

Hmm, I believe that we can deprecate the use of options in ipfsd-ctl for proc types and always use the config key. That will make it consistent across all daemon types, which currently don't use options at all.

[alanshaw]

Any progress on this? I've encountered it again...

[dryajov]

@alanshaw

TL;DR

We should remove the EXPERIMENTAL option altogether and use the args array to communicate those options. In this case, we'll need to add the mapping for --enable-dht-experiment for in-proc nodes.

---

The issue is that we already support the --enable-experimental-.... format through the args array for both in proc and deamons.

Here is what we've got currently:

• the daemon nodes can only enable features through the args array since they are shell commands
• the in proc nodes are ran within the current process, and hence don't support the args array natively and thus are mapped to the EXPERIMENTAL opts to new IPFS({...})

Here is what I think we should do:

• leave the daemons as they are (using the args array with the --FLAG flags)
• remove the EXPERIMENTAL from the in proc nodes altogether and only use args to communicate experimental options along with other possible flags

We can do the cross mapping (i.e. merge the args and the EXPERIMENTAL flags and other options across all implementations), but I think this adds unnecessary complexity and confuses the API.

The main reason I want to use the args array is for backwards compatibility and consistency - this is how all of our nodes are spawned in tests right now.

[jacobheun]

I created #268 to resolve a separate issue I was having with options.Bootstrap not being overridable (which is painful when testing private networks). It does not do what @dryajov is proposing for the experimental args, but it does pass the config to the created IPFS node.

[vasco-santos]

I would go with @jacobheun solution by now, and we can have @dryajov solution afterward. What do you think? @dryajov @alanshaw

[daviddias]

@hugomrdias does this issue still apply?

[hugomrdias]

not sure but i can guarantee in the next version this will not be a problem, already made tests for it