Open pipermerriam opened 5 years ago
Maybe instead of a special API it might just be a different URI format that could be used with the primary package retrieval APIs
Is this more or less a better/more efficient way to install any # of packages, as opposed to fetching them via an on-chain registry?
It's worse or not clearly better than using an on-chain registry if you only want the manifest. However, suppose the python package ships with some python classes that wrap the Contract
APIs (custom classes that add convenience methods). In that model, having the manifests available via this mechanism allow them to be delivered alongside that python code.
BTW, I'm in no way convinced this is something that should be prioritized, just an idea that I wanted to write down.
After a bit more thought, I think this mechanism is objectively better in cases like web3.py where
I think in this case, it is superior.
suppose the python package ships with some python classes that wrap the
Contract
APIs (custom classes that add convenience methods).
Ahh yes that seems like it could be very useful
https://setuptools.readthedocs.io/en/latest/pkg_resources.html#basic-workingset-methods
import pkg_resources
pkg_resources.iter_entry_points('ethpm11')
That returns a generator of whatever entry points have been declared under the given name.
What is wrong
I stumbled across https://github.com/ethereum/web3.py/pull/1242 and though: "Wouldn't it be neat if we could distribute smart contract packages in a first class way from using python packaging."
Which made me think of how pytest does it for plugins.
https://docs.pytest.org/en/latest/writing_plugins.html#making-your-plugin-installable-by-others
So suppose that we used the same API. Here's a sketch of how it might work.
Suppose we create a new project,
vyper-registry
. It's a python package that contains the various manifests for the vyper implementation of the registry contract. That package would ship with those JSON documents as part of the files it installs. Here's a simple example source tree.So this is nice and all, and from another library like
web3.py
we could get at the by 1) knowing where they are and 2) loading them from the filesystem. This works for individual cases, but it fails as a general solution since you have to know how the files are laid out and each project does this differently.This is where setuptools entry points come in. Here's a simple idea of what this might looks like in the
setup.py
of thevyper-registry
package.I haven't dug into the distutils APIs to figure out how we get at these entry points but... lets pretend it looks something like this.
With this, a project like web3 could then do the following.
Whatcha think?