You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.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.
owned==0.1.0 => ipfs://Qm...
ipfs://Qm... > 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 fromowned==0.1.0 > URI
and then we'll need another backend to do the reduction fromURI > 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.
The text was updated successfully, but these errors were encountered: