FireFly Command Line Interface (CLI)

FireFly CLI

The FireFly CLI can be used to create a local FireFly stacks for offline development of blockchain apps. This allows developers to rapidly iterate on their idea without worrying about needing to set up a bunch of infrastructure before they can write the first line of code.

FireFly CLI Screenshot

Prerequisites

In order to run the FireFly CLI, you will need a few things installed on your dev machine:

Install the CLI

On Go 1.16 and newer:

$ go install github.com/hyperledger-labs/firefly-cli/ff@latest

On earlier versions of Go:

$ go get github.com/hyperledger-labs/firefly-cli/ff

Create a new stack

$ ff init <stack_name>

Start a stack

$ ff start <stack_name>

View logs

$ ff logs <stack_name>

NOTE: You can use the -f flag on the logs command to follow the log output from all nodes in the stack

Stop a stack

$ ff stop <stack_name>

Clear all data from a stack

This command clears all data in a stack, but leaves the stack itself. This is useful for testing when you want to start with a clean slate but don't want to actually recreate the resources in the stack itself. Note: this will also stop the stack if it is running.

$ ff reset <stack_name>

Completely delete a stack

This command will completely delete a stack, including all of its data and configuration.

$ ff remove <stack_name>
Owner
Hyperledger Labs provides a space where work can easily be started without the creation of an official Hyperledger project.
null
Comments
  • `ff init -b besu dev1` creates a non-functional installation

    `ff init -b besu dev1` creates a non-functional installation

    When I execute:

    ff init -b besu dev1

    and then:

    ff start dev1

    I get:

    reading stack config... done
    this will take a few seconds longer since this is the first time you're running this stack...
    ⡿ Error: an error occurred - rolling back changes... Error: docker-compose up -d
    Failed [1] Creating network "dev1_default" with the default driver
    Creating volume "dev1_ethconnect_abis_0" with default driver
    Creating volume "dev1_ethconnect_abis_1" with default driver
    Creating volume "dev1_ethconnect_events_0" with default driver
    Creating volume "dev1_ethconnect_events_1" with default driver
    Creating volume "dev1_ipfs_data_0" with default driver
    Creating volume "dev1_ipfs_data_1" with default driver
    Creating volume "dev1_ipfs_staging_0" with default driver
    Creating volume "dev1_ipfs_staging_1" with default driver
    Creating volume "dev1_member1tessera" with default driver
    Creating volume "dev1_public-keys" with default driver
    Creating dev1_validator1_1 ... 
    Creating dev1_ipfs_0       ... 
    Creating dev1_member1tessera_1 ... 
    Creating dev1_ipfs_1           ... 
    Creating dev1_dataexchange_0   ... 
    Creating dev1_dataexchange_1   ... 
    Creating dev1_ipfs_1           ... done
    Creating dev1_member1tessera_1 ... done
    Creating dev1_ipfs_0           ... done
    Creating dev1_validator1_1     ... done
    Creating dev1_rpcnode_1        ... 
    Creating dev1_dataexchange_0   ... done
    Creating dev1_dataexchange_1   ... done
    Creating dev1_rpcnode_1        ... done
    
    ERROR: for firefly_core_0  Container "3d03ad4e2b1a" is unhealthy.
    
    ERROR: for ethsigner  Container "3d03ad4e2b1a" is unhealthy.
    
    ERROR: for member1besu  Container "3d03ad4e2b1a" is unhealthy.
    Encountered errors while bringing up the project.
     - all changes rolled back
    Usage:
      ff start <stack_name> [flags]
    
    Flags:
      -h, --help          help for start
      -b, --no-rollback   Do not automatically rollback changes if first time setup fails
    
    Global Flags:
          --ansi string   control when to print ANSI control characters ("never"|"always"|"auto") (default "auto")
      -v, --verbose       verbose log output
    
    Error: docker-compose up -d
    Failed [1] Creating network "dev1_default" with the default driver
    Creating volume "dev1_ethconnect_abis_0" with default driver
    Creating volume "dev1_ethconnect_abis_1" with default driver
    Creating volume "dev1_ethconnect_events_0" with default driver
    Creating volume "dev1_ethconnect_events_1" with default driver
    Creating volume "dev1_ipfs_data_0" with default driver
    Creating volume "dev1_ipfs_data_1" with default driver
    Creating volume "dev1_ipfs_staging_0" with default driver
    Creating volume "dev1_ipfs_staging_1" with default driver
    Creating volume "dev1_member1tessera" with default driver
    Creating volume "dev1_public-keys" with default driver
    Creating dev1_validator1_1 ... 
    Creating dev1_ipfs_0       ... 
    Creating dev1_member1tessera_1 ... 
    Creating dev1_ipfs_1           ... 
    Creating dev1_dataexchange_0   ... 
    Creating dev1_dataexchange_1   ... 
    Creating dev1_ipfs_1           ... done
    Creating dev1_member1tessera_1 ... done
    Creating dev1_ipfs_0           ... done
    Creating dev1_validator1_1     ... done
    Creating dev1_rpcnode_1        ... 
    Creating dev1_dataexchange_0   ... done
    Creating dev1_dataexchange_1   ... done
    Creating dev1_rpcnode_1        ... done
    
    ERROR: for firefly_core_0  Container "3d03ad4e2b1a" is unhealthy.
    
    ERROR: for ethsigner  Container "3d03ad4e2b1a" is unhealthy.
    
    ERROR: for member1besu  Container "3d03ad4e2b1a" is unhealthy.
    Encountered errors while bringing up the project.
     - all changes rolled back
    
  • Postgres Containers showing fatal permission issue on creation/startup

    Postgres Containers showing fatal permission issue on creation/startup

    Expected Behavior

    ff start [stack_name] should start up stack completely per user prompted information

    Current Behavior

    Upon initializing the stack and issuing the ff start [stack_name] command, containers are spinning up but the postgres containers are failing with apparent permissions errors which cause other containers to fail due to inability to connect to the database container. image

    Context (Environment)

    • OS: Windows 10
    • Terminal: Git Bash
    • Go version: go1.16.5 windows/amd64
    • Docker version: 20.10.6
    • Firefly versions: image

    Attempted Manual Corrections

    I have executed chmod -R 0755 ~/.firefly/stacks/[stack_name]/data/postgres_[N] on each of the indicated node folders.

  • Deploy ERC1155 contract and tokens microservice

    Deploy ERC1155 contract and tokens microservice

    Tokens Docker will need to be deployed before this can work, which implies a dependency on https://github.com/hyperledger-labs/firefly-tokens-erc1155/pull/3. Edit: this pre-req is now done.

  • ff logs not returning any logs

    ff logs not returning any logs

    Issuing ff logs <stack name> doesn't output any logs, it simply prints "getting logs..." and returns.

    Running the equivalent docker compose command manually (docker compose -p <stack-name> logs) correctly outputs logs from all of the running containers to stdout.

  • ERC-20 Token factory CLI support

    ERC-20 Token factory CLI support

    See https://github.com/hyperledger/firefly-tokens-erc20-erc721/pull/44 for changes in the connector.

    If this is a pattern we want to facilitate, the CLI may be adjusted to automatically deploy the "example" token factory contract when using the erc20_erc721 connector, and configure the appropriate address in the connector environment (similar to how the CLI deploys and configures the contract for erc1155).

    Pro: decreases the friction to get a development environment running with ERC20+ERC721 tokens Con: likely doesn't match a typical production contract deployment - might be an incorrect pattern to teach

  • Add support for FireFly Transaction Manager

    Add support for FireFly Transaction Manager

    • Update the ethsigner runtime to a fast starting Go runtime, maintained within the FireFly project
      • https://github.com/hyperledger/firefly-signer
    • Separate -b / --blockchain-provider from a new -n / --blockchain-node option
      • Still supports -b besu and -b geth
      • New syntax -b ethereum -n besu / -b ethereum -n geth
    • Add -b ethereum -n remote-rpc to pick Ethereum with just a signer - no local node
    • Add --remote-node-url to specify the URL of the remote JSON/RPC endpoint (Infura etc.)
    • Add --chain-id option for setting a custom Chain ID for ethereum networks
    • Add --fftm-enabled and --fftm-config options to configure the FireFly Transaction Manager
      • https://github.com/hyperledger/firefly-transaction-manager
      • Starts a copy of the new runtime in the stack for each member, with a default config
      • Allows an override for the configuration to mix in your own YAML
      • Adds config to FireFly Core, and the Token connector(s), to inform them of the FFTM URL
    • Add --request-timeout to ask FireFly Core for a custom timeout (default is 2mins)
      • Useful when the CLI is doing org/node registration against a public chain with confirmations
  • Add memory warning with stacks of more than 3 members

    Add memory warning with stacks of more than 3 members

    Resolves https://github.com/hyperledger/firefly-cli/issues/150

    Unfortunately there does not appear any way to easily programmatically set the Docker VM to use more memory, and the default (2 GB) is pretty lows for running the number of processes required to run a FireFly stack.

    When a stack with more than 2 members (1 GB per member) is initialized, this prints a warning noting that the default may need to be increased.

    As a future enhancement, it would be nice if this warning was only printed if not enough RAM was allocated, but that would require knowing how much RAM the Docker VM currently has allocated. I couldn't find a quick way to do that yet.

    Note: This is not an issue on Linux, because Docker doesn't run in a VM on Linux.

  • Support for Prometheus Metrics Aggregation

    Support for Prometheus Metrics Aggregation

    Description

    Closes #121

    Adds support for optionally enabling the FireFly metrics server and including a Prometheus server container configured to scrape each FireFly's metrics.

    For example, one can create a stack w/ Prometheus enabled (custom manifest used for latest FF image):

    ./ff/ff init --prometheus-enabled=true --manifest=${HOME}/github.com/kaleido-io/firefly-cli/manifest.json dev
    

    results in:

    Screen Shot 2021-11-21 at 8 47 04 PM
  • Intermittent Error 'Failed to write genesis block' while starting a stack

    Intermittent Error 'Failed to write genesis block' while starting a stack

    OS: macOS Version 11.3

    commands run:

    1. ff init trial
    2. ff start trial

    Snippet from the terminal:

    firefly % ff start trial --verbose reading stack config... done this will take a few seconds longer since this is the first time you're running this stack... starting FireFly stack 'trial'... initializing blockchain node /usr/local/bin/docker-compose down --volumes trial Warning: No resource found to remove Error: docker run --rm -v trial_geth:/data ethereum/client-go:release-1.9 --datadir /data --nousb init /data/genesis.json Failed [1] INFO [10-01|19:14:55.834] Maximum peer count ETH=50 LES=0 total=50 INFO [10-01|19:14:55.834] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory" INFO [10-01|19:14:55.835] Set global gas cap cap=25000000 INFO [10-01|19:14:55.835] Allocated cache and file handles database=/data/geth/chaindata cache=16.00MiB handles=16 Fatal: Failed to write genesis block: database contains incompatible genesis (have 4e89bfe2e09d6140e33bd6b48124418bc37dcb8ebaa2f3c9cda65c4e47da5a67, new fa0217c58f30bd25803991de9690f7b39678582443e358819638b4d162a8bf9f) INFO [10-01|19:14:55.844] Persisted trie from memory database nodes=3 size=455.00B time="19.156µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B Fatal: Failed to write genesis block: database contains incompatible genesis (have 4e89bfe2e09d6140e33bd6b48124418bc37dcb8ebaa2f3c9cda65c4e47da5a67, new fa0217c58f30bd25803991de9690f7b39678582443e358819638b4d162a8bf9f)

    • all changes rolled back Usage: ff start <stack_name> [flags]

    Flags: -h, --help help for start -n, --no-pull Do not pull latest images when starting -b, --no-rollback Do not automatically rollback changes if first time setup fails

    Global Flags: --ansi string control when to print ANSI control characters ("never"|"always"|"auto") (default "auto") (default "auto") -v, --verbose verbose log output

    Error: docker run --rm -v trial_geth:/data ethereum/client-go:release-1.9 --datadir /data --nousb init /data/genesis.json Failed [1] INFO [10-01|19:14:55.834] Maximum peer count ETH=50 LES=0 total=50 INFO [10-01|19:14:55.834] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory" INFO [10-01|19:14:55.835] Set global gas cap cap=25000000 INFO [10-01|19:14:55.835] Allocated cache and file handles database=/data/geth/chaindata cache=16.00MiB handles=16 Fatal: Failed to write genesis block: database contains incompatible genesis (have 4e89bfe2e09d6140e33bd6b48124418bc37dcb8ebaa2f3c9cda65c4e47da5a67, new fa0217c58f30bd25803991de9690f7b39678582443e358819638b4d162a8bf9f) INFO [10-01|19:14:55.844] Persisted trie from memory database nodes=3 size=455.00B time="19.156µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B Fatal: Failed to write genesis block: database contains incompatible genesis (have 4e89bfe2e09d6140e33bd6b48124418bc37dcb8ebaa2f3c9cda65c4e47da5a67, new fa0217c58f30bd25803991de9690f7b39678582443e358819638b4d162a8bf9f)

    • all changes rolled back
  • Add helper script for mapping ports out of a FireFly stack

    Add helper script for mapping ports out of a FireFly stack

    I don't know if this is the right place to put this, or if it's even something that needs to be committed. But I created it, and it's helping me do local development on FireFly, so I wanted to share.

    My current local development steps are:

    1. Create a stack using FireFly CLI (init with -d postgres and start with -n)
    2. Run this script and output the config for firefly_core_0 to a new file
    3. Stop the firefly_core_0 container
    4. Run my own instance of FireFly with go run main.go -f <generated-config-file>

    This script can be used to take a FireFly config file and replace internal docker-compose ports with the mapped ports on localhost, generating a new config file that can be exported.

    It's most useful if you want to replace a container in a stack with your own FireFly instance (often necessary during testing and development on FireFly itself).

    Signed-off-by: Andrew Richardson [email protected]

  • Option to generate config for running FireFly core outside docker compose

    Option to generate config for running FireFly core outside docker compose

    For developers working on core, it would be handy to have a mode that generates the YAML files for running core outside of docker-compose using the exposed ports.

    This is a manual activity today, that has to be re-done each time on the ff remove / ff init cycle:

    • ff init / ff start -n
    • Edit docker-compose.yml to comment out one or more firefly_core_0 services
    • Edit firefly_1.core etc. to change all the docker link hostnames, into localhost:510x hostnames
    • ff stop / ff start
    • Run FireFly core (using VSCode launch.json etc)
  • first draft for supporting docker-compose v2

    first draft for supporting docker-compose v2

    Pull Request

    Disclaimer

    I'm not a golang developer, so any code presented here is a collection of educated guesses as how to solve the problem. With that out of the way, let's present the pull request.

    Problem

    This pull request adresses Issue231: firefly fails check for docker compose v2. The problem arises due to docker changing the syntax for docker-compose from docker-compose in version 1 to docker compose in version 2. There is always the workaround to require the standalone docker-compose in version 1.

    Fix

    The fix is split into two parts, adressing the checking of the version and integrating the information into the stack manager that executes the docker commands via RunDockerComposeCommand. The information about which version syntax to use for the commands is carried via context.

    CheckDockerConfig

    the function that checks for the prerequisites when executing docker-compose commands, CheckDockerConfig returns a tuple (DockerComposeVersion, error) with DockerComposeVersion as enum to differentiate between None, ComposeV1 and ComposeV2. This value is stored in a context that is later transferred into the stack manager. Unfortunately, cobra with version 1.4.0 does not provide the capability to allow context to be attached to a command. Only from version 1.5.0, this feature has been merged, for reference: support for SetContext. The solution using cobra 1.5.0 concerns all commands which use both PreRunE and RunE while also requiring the docker compose version to be transferred as context between these two executions:

            PreRunE: func(cmd *cobra.Command, args []string) error {
    		ctx := ...
    		version, err := docker.CheckDockerConfig()
    		ctx = context.WithValue(ctx, docker.ComposeVersion{}, version)
    		cmd.SetContext(ctx)
    		return err
    	},
    	RunE: func(cmd *cobra.Command, args []string) error {
                    ...
    		stackManager := stacks.NewStackManager(cmd.Context())
                   ...
    	},
    

    The functions currently affected are defined in:

    • accounts_create.go
    • accounts_list.go
    • deploy_ethereum.go
    • deploy_fabric

    No version update is required when simply combining both executions, similar to functions from:

    • info.go
    • logs.go
    • reset.go
    • start.go
            RunE: func(cmd *cobra.Command, args []string) error {
    		ctx := ...
    		version, err := docker.CheckDockerConfig()
    		ctx = context.WithValue(ctx, docker.ComposeVersion{}, version)
                    if err != nil {
                         return err
                    }
    		stackManager := stacks.NewStackManager(cmd.Context())
                   ...
    	},
    

    RunDockerComposeCommand

    The second part of the changes affects the way the stack manager runs docker-compose functions. By retrieving the docker-compose version, either docker-compose or docker compose can be executed

    Possible Tweaks

    • Instead of storing a version in the context, the command itself can be stored; when docker-compose in version 2 is detected, instead storing V1, the string docker compose is attached to the context with ComposeCmd as key. Consequently, the RunDockerComposeCommand function simply executes exec.Command(ctx.Value(ComposeCmd{}), command...).

    Open Question

    • Is the separation between PreRunE and RunE necessary, because currently only docker checks are executed in PreRun. Small commands do not even specify PreRunE at all.
  • firefly fails check for docker compose v2 due to wrong flag `-v`

    firefly fails check for docker compose v2 due to wrong flag `-v`

    Issue

    This is a simple issue. When creating a new stack and trying to start the stack, an error is thrown:

    Error: an error occurred while running docker-compose. Is docker-compose installed on your computer?
    Usage:
      ff start <stack_name> [flags]
    ...
    

    I can confirm that docker and compose as part of the cli is installed correctly. Below the output for the versions used by my setup

    docker version

    docker compose version

    # docker version ######################################################
    
    Client: Docker Engine - Community
     Version:           20.10.21
     API version:       1.41
     Go version:        go1.18.7
     Git commit:        baeda1f
     Built:             Tue Oct 25 18:01:19 2022
     OS/Arch:           linux/arm64
     Context:           default
     Experimental:      true
    
    Server: Docker Engine - Community
     Engine:
      Version:          20.10.21
      API version:      1.41 (minimum version 1.12)
      Go version:       go1.18.7
      Git commit:       3056208
      Built:            Tue Oct 25 17:59:41 2022
      OS/Arch:          linux/arm64
      Experimental:     false
     containerd:
      Version:          1.6.10
      GitCommit:        770bd0108c32f3fb5c73ae1264f7e503fe7b2661
     runc:
      Version:          1.1.4
      GitCommit:        v1.1.4-0-g5fd4c4d
     docker-init:
      Version:          0.19.0
      GitCommit:        de40ad0
    
    # docker compose version ###############################################
    Docker compose version v2.12.2
    
    # firefly version #######################################################
    {
      "Version": "1.1.2",
      "Commit": "8b462fff760e1c7cc1d11c3ddb34638c094b0f2e",
      "Date": "2022-11-17T21:16:50Z",
      "License": "Apache-2.0"
    }
    

    I tried to alleviate the problem by providing aliasing or a redirect using a script file /bin/docker-compose. Both tricks work but do not solve the error.

    Cause

    A little inspection of the source code points to the version check failing since docker-compose -v translated to docker compose -v does not exists as valid command; the flag -v has been replaced by version.

    The line throwing the error is CheckDockerConfig.

    Non-invasive Workaround

    A fix that does not include changing any source code is done by creating a file /bin/docker-compose that captures and delegates the correct call:

    #file content of /bin/docker-compose
    if [[ $1 == '-v' ]]; then
            docker compose version
    else
            docker compose $@
    fi
    
  • All hex address values should be wrapped as HexAddress

    All hex address values should be wrapped as HexAddress

    Due to https://github.com/go-yaml/yaml/issues/847, we have a wrapper type for hex addresses that will explicitly quote them as strings: https://github.com/hyperledger/firefly-cli/blob/main/pkg/types/hex_address.go

    This is used sparingly right now, but should be used for all hex addresses output by the CLI.

  • Specify sequence number with ff deploy

    Specify sequence number with ff deploy

    As a developer, I want to update easily my chaincode on my local instance of Firefly. I can do the first deploy as intended, but obviousely later deploys must have a greater sequence number. I understand that ff deploy is more intenteded for CI, but it would be a great feature for easier testing.

    I have two suggestions:

    1. add a --sequence/-s parameter or an additional optional arg to ff deploy to specify the sequence number
    2. or automate the thing and make the sequence number auto-incremented (I've done this in bash by counting the commited chaincodes)

    Thanks a lot

  • No easy way to see which stacks(s) are running

    No easy way to see which stacks(s) are running

    You can use "ff info -v" to view the docker images and ps output, but ps will show exited containers as well as running ones and is quite verbose in its output. It would be good to have a way of showing which stacks you have running without having to visually parse docker ps output.

    Something like:

    mwhitehead $> ff info devgateway Status: Running Number of running containers: 6 Your docker compose file for this stack can be found at: /Users/mwhitehead/.firefly/stacks/devgateway/docker-compose.yml

    would be really useful.

  • Add brew tap for firefly-cli release through goreleaser

    Add brew tap for firefly-cli release through goreleaser

    This PR adds brews section to .goreleaser.yml file.

    use on commandline:

    brew tap hyperledger/packages/firefly-cli
    brew install firefly-cli
    

    TODO: create repo hyperledger/homebrew-packages

    • this is where homebrew will store the .rb file under Formula folder

    ISSUE: https://github.com/hyperledger/firefly-cli/issues/59

Package command provide simple API to create modern command-line interface

Package command Package command provide simple API to create modern command-line interface, mainly for lightweight usage, inspired by cobra Usage pack

Jan 16, 2022
An unofficial command line interface (CLI) for ASPEN's Oneliner application

Overview OlxCLI is an unofficial command line interface (CLI) for ASPEN's Oneliner application. The CLI provides commands for running common fault sim

Jan 3, 2022
Free5GC Network Function (NF) Command Line Interface (CLI)

NFCLI free5GC Network Function (NF) Command Line Interface (CLI) based on Thrift Thrift Installation Steps Donwload Thrift 0.15.0 ./bootstrap.sh ./con

Jan 11, 2022
Subnet-cli - A command-line interface to manage Avalanche Subnets
Subnet-cli - A command-line interface to manage Avalanche Subnets

subnet-cli A command-line interface to manage Avalanche Subnets. Install git clo

Nov 26, 2022
bluemonday-cli is a simple command-line interface to bluemonday

bluemonday-cli bluemonday-cli is a simple command-line interface to bluemonday. We've configured bluemonday for ROVR's specific requirements. It reads

Jan 24, 2022
An open-source GitLab command line tool bringing GitLab's cool features to your command line
An open-source GitLab command line tool bringing GitLab's cool features to your command line

GLab is an open source GitLab CLI tool bringing GitLab to your terminal next to where you are already working with git and your code without switching

Dec 30, 2022
A command line tool that builds and (re)starts your web application everytime you save a Go or template fileA command line tool that builds and (re)starts your web application everytime you save a Go or template file

# Fresh Fresh is a command line tool that builds and (re)starts your web application everytime you save a Go or template file. If the web framework yo

Nov 22, 2021
A command line tool to prompt for a value to be included in another command line.

readval is a command line tool which is designed for one specific purpose—to prompt for a value to be included in another command line. readval prints

Dec 22, 2021
git-xargs is a command-line tool (CLI) for making updates across multiple Github repositories with a single command.
git-xargs is a command-line tool (CLI) for making updates across multiple Github repositories with a single command.

Table of contents Introduction Reference Contributing Introduction Overview git-xargs is a command-line tool (CLI) for making updates across multiple

Dec 31, 2022
git-xargs is a command-line tool (CLI) for making updates across multiple GitHub repositories with a single command
git-xargs is a command-line tool (CLI) for making updates across multiple GitHub repositories with a single command

git-xargs is a command-line tool (CLI) for making updates across multiple GitHub repositories with a single command. You give git-xargs:

Feb 5, 2022
Command Line Interface for Terraform Enterprise/Cloud ( tecli )
Command Line Interface for Terraform Enterprise/Cloud ( tecli )

In a world where everything is Terraform, teams use Terraform Cloud API to manage their workloads. TECLI increases teams productivity by facilitating such interaction and by providing easy commands that can be executed on a terminal or on CI/CD systems.

Dec 16, 2022
a command line interface to orbit.love

orbit-cli NAME: orbit-cli - a command line interface to orbit.love USAGE: orbit-cli [global options] command [command options] [arguments...]

May 18, 2021
Lux is a command-line interface for controlling and monitoring Govee lighting strips built in Go.

What is Lux? Lux is a command-line interface for controlling and monitoring Govee lighting strips built in Go. Lux provides it's users with the abilit

Dec 28, 2022
Command line interface for flomo.

flomo-cli A Golang based command line interface of flomo. 中文说明 Features Type and save to flomo using command line. Editor mode supports, able to use v

Sep 19, 2022
Gofire 🔥 Command Line Interface Generator tool for Go
Gofire 🔥 Command Line Interface Generator tool for Go

Gofire ?? : Command Line Interface Generator tool for Go Introduction Gofire is the tool for Go that automatically generates a command line interface

Dec 6, 2022
Command line interface for control iTunes
Command line interface for control iTunes

iTunes CLI Command line interface for control iTunes Description You can control iTunes operations from command line. Equipments macOS Sierra or later

Sep 30, 2022
A command line interface for trying out Repustate's multilingual semantic search
A command line interface for trying out Repustate's multilingual semantic search

rcli A command line interface for trying out Repustate's multilingual semantic search. Install & Usage Download the binary for your OS. Make sure it's

Nov 26, 2020
Inotify-tools is a C library and a set of command-line programs providing a simple interface to inotify.

inotify-tools This is a package of some commandline utilities relating to inotify. The general purpose of this package is to allow inotify's features

Jan 4, 2023
kcli: command line interface tool to interact with K8trics API server as well as manage its lifecycle
kcli: command line interface tool to interact with K8trics API server as well as manage its lifecycle

K8trics CLI (kcli) kcli is command line interface tool to interact with K8trics API server as well as manage its lifecycle. kcli can provision and dep

Dec 15, 2021