Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stub out Package Manager API #21

Open
pipermerriam opened this issue Dec 13, 2017 · 0 comments
Open

Stub out Package Manager API #21

pipermerriam opened this issue Dec 13, 2017 · 0 comments

Comments

@pipermerriam
Copy link
Member

What was wrong?

Being able to deal with individual packages (and their dependencies) is good, but a higher level of abstraction is needed for this library to be truly useful and allow packaging to be a black box for other libraries that use this tool.

How can it be fixed?

Implement a new PackageManager class. This class will be responsible for the following things.

  • Given a set of packages, install them.
  • Managing the set of currently installed packages.
  • Backend style API for sourcing packages to be installed (like from a package index contract).

Low level package installation

Assuming we have a collection of the package data for a number of packages, installation is the process of writing those to disk in some structured way. This should be written as a simple pluggable backend system so that we can support multiple installation schemes.

Our initial default installation scheme will be derived from the code found at populus/packages/installation.py.

TODO: translate that code to a spec here or in a dedicated issue linked from here.

Managing packages

This is a slightly higher level interface that should cover installation, upgrading, and removal of packages.

TODO: do we need to support a package.json document of some sort?

In addition, we should support pip freeze style exporting of currently installed packages.

Package Backends

The heavy lifting is going to exist in the various package backends. A package backend is responsible for sourcing package data to be used for package installation.

We need to support the following use cases across some minimal set of default backends.

  • Human readable strings to URI: owned==0.1.0 => ipfs://Qm...
  • IPFS URI to package data: ipfs://Qm... > package_data
  • Filesystem paths to package data: /path/to/package.json => package_data

It's worth noting that ultimately, we need to have everything reduce down to package_data but some sources like a package index may only do a partial reduction from owned==0.1.0 > URI and then we'll need another backend to do the reduction from URI > package_data. This structure is already in place in the populus codebase and should be used as a starting point for this functionality.

TOOD: new ticket with thorough spec on how this API should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant