pip support

[jessebmiller]

Is there any chance for a pip package that works with populus the way the npm package works with truffle?

I might be up for making a pull request if I could get a little guidance on how it would work.

[federicobond]

We would be very interested in that @jessebmiller. Have you read this section in the Populus docs? Let me know how can I help you make that happen!

[jessebmiller]

Thanks for that link @federicobond, I'll take a look and see what direction I might need to get going.

[federicobond]

Great! Looking forward to that. I'll assign you the issue, please let me know if you are unable to work on it for any reason so others may grab it.

[jessebmiller]

I've been unable to get populus package... working, which I think is an issue that needs to be filed over there. I'll also continue to look into what could be done with pip.

[jessebmiller]

I've been able to get pip to install the contracts in <project root>/installed_packages/zeppelin-solidity/contracts with this pip install --root <project root> <package> but that hasn't let me import them as I expected. I'm reaching out to the populus folks to see if I can track down what's going wrong. If anyone has any ideas here is my fork. https://github.com/jessebmiller/zeppelin-solidity

[federicobond]

Have you found any other packages that have solved it already, that may serve as a base for this work?

[jessebmiller]

I have not, though I expect that it has to do with the way populus is handling (or not handling) installed packages. I'll see what I can find though.

[jessebmiller]

Got this response from the populus glitter channel

Piper Merriam @pipermerriam 11:45
@jessebmiller that functionality is not going to work right now. There was originally a v2 branch incoming with package management but it got delayed (current V2 is not that v2)

I could update the packaging to put a zeppelin-solidity folder right in the contracts folder and then import them with relative paths. any preference? Is that too much of a hack?

[federicobond]

I don’t think so, and I would very much like to support the Populus ecosystem but this requires changes to the release process, so I would like to get @frangio’s opinion first.

[jessebmiller]

To be clear @frangio it would not require changing the structure of this repo, just adding setup.py, setup.cfg and MANIFEST.in to the root. I'd have the setup.py and setup.cfg to install the zeppelin-solidity contracts into the populus project at <project root>/contracts/zeppelin-solidity/contracts/... with a pip command pip install --root <project root> zeppelin-solidity

This would need to be published to PyPi to be installed under that name, but even without that people could install from the a github url.

This would be a temporary solution. Once populus implements packaging they will likely put packages into installed_packages and provide a command populus package install zeppelin-solidity for ERC190 packages.

[frangio]

Agreed with @federicobond that we're interested in supporting the Populus ecosystem. I'm not familiar with it or PyPI, though. I don't think it would be much a problem to add the necessary files in the repo, as long as someone with the knowledge can maintain them. I would be ok with the extra step of publishing releases to PyPI.

@jessebmiller Can you create a PR with the proposed changes so we can see what it'd look like?

[jessebmiller]

Yeah I'll put that together.

[aunyks]

Has this been implemented? If not, what's still blocking?

[frangio]

@aunyks No, it hasn't. Personally I'm not sure that it will be a good idea for us to support two different package managers/ecosystems at this stage in which we're still figuring a few things out. Additionally, no one among the current maintainers is familiar with Ethereum's Python tooling so we won't be able to give good support for it.

I'm marking this as discussion to hear some more opinions.

[aunyks]

Very well. I'd love to see this in the Python side of the community at some time in the future! Hopefully we'll see more convergence between Ethereum JS and Py dev experiences.

[nventuro]

Closing due to inactivity. For what it's worth, @frangio's comment here still applies.

[jpez16]

@frangio do we have any new thoughts on this?

[frangio]

We still prefer sticking to a single package manager/distribution channel. If we were to distribute the package in a new way, the new version of ethpm would probably be considered with higher priority since it is designed to be Ethereum-native.