Pack infra

Jump to bottom Edit New page

Anne Ogborn edited this page Dec 3, 2016 · 7 revisions

The pack system is not robust enough and is missing some features.

Features

pack_upgrade/1 should recursively upgrade Pack dependencies.
Improved Pack validation through code analysis, assessing conflicts, security risks and conformance to standards. Low-hanging fruit may be to copy what the ClioPatria package manager currently does. Validation may include:
- Missing meta declarations.
- Non-module files.
- Undefined predicates (list_undefined/1).

Documentation

Intended workflow for local Pack development
What does option interactive/1 of pack_install/2 do exactly?
Unify nomenclature in documentation and on Web site.
- The following nomenclature is currently used:
  - "Packs" to denote community extensions.
  - "Packages" for libraries that are included in the SWI sources but that can be left out during compilation from sources.
  - "Add-ons" to denote community extensions.
- Suggestion:
  - Replace all mentions of "Add-ons" with "Packs".
  - Come up with a new term for "Packages".
Describe best practices for Pack directory structure. Current Packs already use some de-facto patterns. Categories of files that may occur in a Pack and that may be treated specially:
- Documentation
- Examples
- Initialization scripts
- Legacy code
- Tests (e.g., pack_run_tests/1 may run these using plunit)
- Web resources

Debug tools

Better debug messages

Robustness

Authorship

currently nothing proves an author's identity. In the event of a name collision, last uploaded wins. Signing the pack could allow some assurance one was installing the 'real' pack. Sally makes pack foo. She publishes with a new pack_publish predicate that takes a secret key. Once a repository knows about foo, it won't update unless the same key was used to sign the pack, and pack_install won't reinstall known packs with mismatched keys.

Code cleanup

More code reuse between pack_install/[1,2]