embarklabs / embark

Framework for serverless Decentralized Applications using Ethereum, IPFS and other platforms
https://framework.embarklabs.io/
MIT License
3.79k stars 493 forks source link

EthPM support #1023

Open Eenae opened 5 years ago

Eenae commented 5 years ago

Overview

TL;DR Wishrequest: it'd be extremely helpful to have EthPM support in embark.

Extra Detail

https://www.ethpm.com/registry is gaining acceptance and some packages are now provided via EthPM, not via npm. Truffle has builtin support of EthPM: truffle install modue-name. It'd be extremely helpful to have EthPM support also in embark.

0x-r4bbit commented 5 years ago

@Eenae thanks for reaching out here!

I do agree that, in the long term, the ecosystem should switch to a decentralized package manager.

Can you elaborate on what that "integration" with embark should look like? The reason I'm asking is that those are obviously two very different tools. So I wonder what exactly would be "extremly helpful" if that integration existed.

Looking forward to your feedback Alex!

Eenae commented 5 years ago

@PascalPrecht thanks for prompt response!

I see this integration as at least two features:

  1. ability to install EthPM package via embark subcommand (a-la truffle install modue-name). Unfortunately, looks like ethpm does't have its own executable entry point in bin/.
  2. automatically add installed contracts to solc paths and make them available for import: e.g. make installed_contracts/zeppelin/contracts/math/SafeMath.sol available as less cumbersome zeppelin/math/SafeMath.sol (again, I took it from truffle).
0x-r4bbit commented 5 years ago

Hey @Eenae

thanks for clarifying this!

Unfortunately, looks like ethpm does't have its own executable entry point in bin/.

If by that you mean it doesn't come with its own executable so it can be run as ethpm install <foo> then introducing a subroutine that calls its APIs probably makes most sense. Other than that, we'd really just be dealing with embark install <foo> vs ethpm install <foo>, so I have to play devil's advocate here and ask how much sense it really makes to introduce really just an "alias" here on our side :)

Again, considering that ethpm doesn't have its own executable (yet?), it might make sense. But once that is available I don't see too much value in having this as a subcommand inside Embark.

automatically add installed contracts to solc paths and make them available for import: e.g. make installed_contracts/zeppelin/contracts/math/SafeMath.sol available as less cumbersome zeppelin/math/SafeMath.sol (again, I took it from truffle).

Is this standardized by Ethpm? As in, does it already add installed contracts to solc paths? That would be indeed an improvement in terms of Developer Experience.

jrainville commented 5 years ago

Hi, just adding to the point of facilitating the import for zeppelin and others. We added the possibility to import from different sources easily to make it easy to use contarcts like those of zeppelin.

You can read more on it here: https://embark.status.im/docs/contracts_imports.html

eg:

import "https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ownership/Ownable.sol";

Embark downloads it for you and resolves the imports (even if the other contract has other imports too).

Eenae commented 5 years ago

Is this standardized by Ethpm? As in, does it already add installed contracts to solc paths? That would be indeed an improvement in terms of Developer Experience.

I'm not sure if it's a task of EthPM to manage solc paths. I think more high-level entity should manage it and set a standard.

import "https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ownership/Ownable.sol";

Thanks! Personally I consider such an import as quite error-prone practice.

jrainville commented 5 years ago

If you prefer, you can npm install the package you want to use and import from node_modules like so:

import "openzeppelin-solidity/contracts/ownership/Ownable.sol";
Eenae commented 5 years ago

Sure, classic way.