singletons module prevents using with embark

[NoahMarconi]

To use with embark I had to clone the repo locally and comment out the module:

module.exports = {
  balance: require('./src/balance'),
  BN,
  constants: require('./src/constants'),
  ether: require('./src/ether'),
  expectEvent: require('./src/expectEvent'),
  makeInterfaceId: require('./src/makeInterfaceId'),
  send: require('./src/send'),
  shouldFail: require('./src/shouldFail'),
  // singletons: require('./src/singletons'),
  time: require('./src/time'),
};

[nventuro]

Hello @NoahMarconi, thank you for reporting this!

What causes the issue? Is it the setting of the provider in this line?

openzeppelin-test-helpers/src/singletons.js

Line 17 in 3eff5bc

ERC1820RegistryArtifact.setProvider(web3.currentProvider);

I'm not too familiar with Embark's environment, but some of our helpers do sort of assume truffle is being used: there's a plan to relax this requirement (#11), but we haven't got around to it yet.

[NoahMarconi]

That's the line that breaks it!

It's not severe enough to stop my project from moving forward; only prevents me from using the deployed package from NPM directly.

[frangio]

Interesting.

@NoahMarconi How does one retrieve the current provider in Embark?

[NoahMarconi]

Not sure myself. I relayed the question on their gitter to see if someone more familiar can answer.

[frangio]

We added a feature a few days ago to be able to use a web3 instance that is not global. It might help in this scenario. It's not released yet, it will be released next week probably. See Configuration in the readme.

In any case, the provider is only necessary to set up an instance of truffle-contract, which doesn't make sense in an Embark environment. We should look into allowing use of an Embark-native contract abstraction, which is essentially what #11 is for. Perhaps we could mitigate it by making modules load in a lazy way so that each one can be used individually. I'll open a PR for this later.

[frangio]

I'm closing this as fixed by #41 because it will now be possible to use the package even if the singletons module doesn't work. This will very likely be released next week.

If you have any more issues with Embark please report them! We're interested in getting this to work.

You're also welcome to join our forum if you need any other kind of help. http://forum.zeppelin.solutions

[NoahMarconi]

Awesome, I'll watch for the release. Thanks so much for the help and quick fix!

[NoahMarconi]

If it helps for future fixes, they replied on gitter. web3Provider is not initialized globally at fist, so adding an initialization step to singleton could work (instead of assuming initialized web3 at the time of importing the module).

NoahMarconi @NoahMarconi May 14 18:14
Anyone know how to retrieve the current provider in Embark? It's coming up as a problem here: OpenZeppelin/openzeppelin-test-helpers#40

Embark Bot @embarkbot_gitlab May 14 20:45
3esmit@discord You can access current provider loading it from web3, do it on the callback/promise of enableEthereum()
3esmit@discord If you mean the spec/tests, you just do it on the before hook

Embark Bot @embarkbot_gitlab May 14 20:52
3esmit@discord Your issue could being caused due web3.currentProvider not being yet available. Overall web3 should be regular web3.js
3esmit@discord Embark deals with web3 initialization/connection for you, based on embarkConfig. But you need to request it after web3 browser connected with embark.

Embark Bot @embarkbot_gitlab May 14 20:59
3esmit@discord EmbarkJS.onReady((err) => { if (err) { //provider is will not be available. } //now you can use web3.currentProvider });