Skip to content
This repository was archived by the owner on Dec 16, 2025. It is now read-only.
This repository was archived by the owner on Dec 16, 2025. It is now read-only.

feat: Add support for local package download #1

@dvinubius

Description

@dvinubius

Details

The currently supported workflow, which is based on interacting with a new process from the aos-cli (load the APM blueprint, then install packages), is only suitable for smaller scale projects with no need for local testing.

When developing a process that relies on APM packages, local testing of the process is not possible since there is no way to install APM package code locally, so that the developed process may require it from a local directory.

In case of complex projects it's a necessity to develop a suite of unit tests and integration tests which involve no deployment on AO. This is possible with approaches such as here.

But if the process being developed relies on APM packages, such a local test setup is currently not possible.

Suggestion

To create a simple CLI tool that - similar to npm - allows the developer to locally install packages.

As a developer of a process that uses an APM package, I would

> apm install @autonomousfinance/ownable

such that the code would be downloaded into a local apm_modules directory.

The cli tool could obtain the code via the arweave gateway, by querying for messages tagged Action = "APM.PublishResponse" that were sent by the APM process.

Simple is enough

I think a tool like this would already be immensely useful even without automatic dependency resolution & inclusion, like npm provides it. So far there aren't even any APM packages relying on each other. But this would be definitely a great feature to add in a second iteration.

Also, it would be no big deal to locally work around the difference in the require path. Meaning:

  • in production, my process would require "@autonomousfinance/ownable"
  • in local development I would have the process do require "apm_modules/@autonomousfinance/ownable".
    There are accessible ways to even automate this, so no worries there.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions