Introduce CLI for Perper

[branimirangelov]

Use Golang to create CLI for Perper with the following scope:

Phase 1

1. Manage Perper Fabric container (run, stop, restart)
2. Run multiple agents (former modules) in correct order.

Phase 2
3. Use git to pull / manage dependent agents (use Git as access control).
4. Manage / Configure test bed (TBD) + mock (TBD)

Optional (Brainstorming)
5. Project skeleton setup

Implementation Notes

Create feature branch feat/cli and cli folder on top level.

[branimirangelov]

First focus:
0. Pre-requisites: Golang and Azure Function Core Tools (latest)

1. Automatic management (in background) of Perper Fabric: docker run -p 10800:10800 -p 40400:40400 -it obecto/perper-fabric
   1.1. Use samples/DotNet.FunctionApp and start it using func start
2. Add optional explicit commands argument: start, restart, stop.

[branimirangelov]

Second focus (multiple agents):

1. Typical Perper application (multi-agent application) structure should look like:

|
+--+project
|  |
|  +--+agent1 (git repo)
|  |  |
|  |  +--+src
|  |  |
|  |  +--+.perper
|  |
|  +--+agent2 (git repo)
|  |  |
|  |  +--+src
|  |  |
|  |  +--+.perper

2. There will be .perper configuration file for every agent that will state the agents that the agent depends on. The format of the file should be TOML (YAML, suggestions?) and there should be an entry that defines what is the name of the agent and the git repo.

3. When starting an agent, the CLI should first start the agents in the .perper file of the agent (recursively)

4. For this phase, assume that all agents are already pulled on the file system (no Git integration for now)

@IoanStoianov and @bojidar-bg - please review and add feedback.

[IoanStoianov]

I would suggest adding a file under the project folder for example: .perper-project which will contain a map agent - > directory path. I think that this will be more "expected/stable" behavior than going through the project folders searching for host.js for the agents.

The idea with recursive .perper is good. We will generate DAG and instantiate the agents. I suppose we are going to generate a folder like node_modules which will contain the agents on which we depend on.

[bojidar-bg]

A) For the TOML file format, I was thinking of something along the lines of this:

[agent]
name = "SampleAgent"
...
[dependencies]
AnotherAgent = "https://github.com/perper/AnotherAgent.git"
# ? AnotherAgentWithPath = "https://github.com/perper/Agents.git#/AnotherAgentWithPath"
# ? AnotherAgentWithRef = "https://github.com/perper/Agents.git#commit"

With that format, there remains the question of what the keys in the [dependencies] section mean. In particular, consider the case when AnotherAgent, referred by the above TOML, has perper.toml with agent.name = "NotAnotherAgent".

C) I think what @branimirangelov was suggesting is to detect what repositories are present in the workspace (and, in later versions, clone the missing ones as needed). That way, agents can refer to each other by full git URLs, yet the user would be able to simultaneously develop a number of them without having to resort to editing perper.toml files (or similar).

D) I think that @IoanStoianov's proposal for a .perper-workspace (or similar, though "workspace" is more precise than "project") file listing all the cloned agents in the workspace is superior to iterating the directories, because:

• If we decide to allow running perper start (or similar) from a subfolder, we can easily find the nearest workspace file in the parent folders. Iterating subdirectories would require finding the nearest perper TOML file, getting its parent folder, and finally iterating that.
• A workspace file may list files outside the working directory, e.g. for vendored agents, without cluttering the developer's working directory. Using subdirectories would require using a special subfolder for such agents, e.g. vendor/.
• A workspace file may list submodules, in the rare cases those are used for dependency management. Iterating subdirectories would require one to check for submodules and add those recursively to the list of cloned repositories.

However, iterating subdirectories has some benefits of its own, such as not requiring yet another file (and one that is just a list of paths, at that). Thus, I remain unconvinced either way.

[bojidar-bg]

As discussed: monorepo structure:

|
+--+project (git repo or subfolder of one)
|  |
|  +--+agent1
|  |  |
|  |  +--+host.json
|  |  |
|  |  +--+.perper
|  |
|  +--+agent2
|  |  |
|  |  +--+host.json
|  |  |
|  |  +--+.perper