SKILL Package Management Proposal

[curtisma]

Problem Statement

We need a way to manage SKILL packages and keep track of the following meta data for the project:

• version number
• SKILL packages

We should be able to "import" packages to avoid defining them globally.

Proposed Solution

A SKILL package is described in "Using SKILL++" section of the SKILL User's guide as a "named let", a let that returns a DPL (decomposed property list)

Each project will have a top-level SKILL package called a "project package" whose symbol is in the Virtue projects and modules tables. Its symbol is named after the project.

The top-level SKILL package for a project, the "project package" will have a method to create a new package. This will register the package with the project package. The project package will be an item directly in the Import table.

We can import sub-packages from the project's top-level "project package"

local packages will be defined as part of a let at the beginning of a file similar to local variables.

letseq(
  ((StrTrim Virtue->Import[Str]->trim)
    (Build Virtue->Import[List]->Build]))
    (Str Virtue->Import[Str)]
    (Prefixp Str->Prefixp))

  ...)

Example package definition

---

let((Modules Virtue->Import[Modules]

Modules->New('package let(()

...


list(nil
  'SomeFunction SomeFunction
  'OtherFunction OtherFunction
))

Alternatives Considered

• There is an existing SKILL package Manager, SPAM. However, it isn't maintained with no commits for the last 3 years. It's also written in scheme format rather than using c-style functions. We should learn what we can from how it worked though.
• skillx

Proposed Action Plan

• 1. Add module import feature
• 2. We'll do that
• 3. Then we'll add tests for this and that.

[tbrandtner]

Hi Curtis,
very interesting feature. I'm also longing for a Skill package manager. But I would not call it SPAM (although I'm a fan of Monty Python ...)
One feature I would like to see in such a "package Skill++ environment" is the support of different version of one package inside the same Virtuoso session. We often have the need to update Skill code because some central procedures have been updated - either you try to stay compatible with old procedural parameter list, but sometimes you want to introduce something real new. Or the central procedures are copied as local procedures into new Skill code. And that's awful. So if an existing Skill package could still work with old version of another package - and in parallel one can uses another Skill tool which uses a newer version of that other package, that would be great.

[curtisma]

Hey Thomas,
I just implemented the first draft of this using Python packages which contain SKILL code. I will present on it during my presentation on Thursday. You can find an explanation in the documentation under overview->packaging

The idea is to install Virtue packages using pip or Conda that contain both a Python as well as Virtue Skill++ packages. Then you can use the virtue CLI with the virtue install command to help install initialization files and load them in the Virtuoso SKILL environment so all the packages are initialized through a single Virtue skill environment initialization file..

Then you can check which SKILL packages are installed using the virtue list command and get information on the Virtue SKILL environment from the active Python environment using the virtue info command.

It's usually much easier to handle these issues by moving them into Python and reusing existing solutions as much as possible so we don't have to reinvent the wheel.

We could even provide a gui for inspecting the Virtue SKILL environment inside Virtuoso by calling the virtue CLI from SKILL.

-Curtis

[curtisma]

The version issue could be handled by being able to activate and deactivate different virtual environments.

We could also consider supporting multiple versions of a package within a single Virtue SKILL environment. This would be more complicated than the virtual environments but could be necessary in certain cases or provide performance benefits. The Virtue SKILL++ packages should be able to enable this since they're installed into the Import table and so we could select different versions when they are imported into a particular let statement's lexical scope.