Merge pull request #1114 from input-output-hk/update-flake-parts

chore: update flake-parts to wrap std

Author: bernokl

compose/smash/README.md

@@ -1,4 +1,4 @@
 # Cardano JS SDK | Smash Server
 
 Dockerized Cardano Smash Server based on Ubuntu. Downloads the Smash Server binary, configures and runs
-it. `inputoutput/cardano-db-sync` image is not used since it doesn't contain Smash Server binary. This Docker image is intended for testing and development purposes only. 
+it. `inputoutput/cardano-db-sync` image is not used since it doesn't contain Smash Server binary. This Docker image is intended for testing and development purposes only.

compose/smash/init.sh

@@ -4,8 +4,7 @@ DB=$(cat /run/secrets/postgres_db_db_sync)
 PASSWORD=$(cat /run/secrets/postgres_password)
 USER=$(cat /run/secrets/postgres_user)
 
-
-echo "postgres:5432:${DB}:${USER}:${PASSWORD}" > /config/pgpass
+echo "postgres:5432:${DB}:${USER}:${PASSWORD}" >/config/pgpass
 
 _term() {
   kill $CHILD
@@ -14,9 +13,9 @@ _term() {
 trap _term SIGTERM
 
 PGPASSFILE=/config/pgpass cardano-smash-server \
-     --config /config/config.json \
-     --port 3100 \
-     --admins /config/smash-admins.txt &
+  --config /config/config.json \
+  --port 3100 \
+  --admins /config/smash-admins.txt &
 
 CHILD=$!
 wait "$CHILD"

flake.lock

@@ -1,6 +1,8 @@
 {
   inputs = {
     nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
+    flake-parts.url = "github:hercules-ci/flake-parts";
+
     devshell.url = "github:numtide/devshell";
 
     n2c.url = "github:nlewo/nix2container";
@@ -15,23 +17,30 @@
   };
 
   outputs = {std, ...} @ inputs:
-    std.growOn {
-      inherit inputs;
-      cellsFrom = ./nix;
-      cellBlocks = with std.blockTypes; [
-        # Software Delivery Lifecycle (Local Development Environment)
-        (devshells "envs")
-        (runnables "jobs")
-        # Software Delivery Lifecycle (Packaging Layers)
-        # For deeper context, please consult:
-        #   https://std.divnix.com/patterns/four-packaging-layers.html
-        (installables "packages" {ci.build = true;})
-        (runnables "operables")
-        (containers "oci-images" {ci.publish = true;})
-        (kubectl "deployments" {
-          ci.diff = true;
-          ci.apply = true;
-        })
+    inputs.flake-parts.lib.mkFlake {inherit inputs;} {
+      imports = with inputs; [
+        std.flakeModule
+        devshell.flakeModule
       ];
+      systems = ["x86_64-linux"];
+
+      std.grow = {
+        cellsFrom = ./nix;
+        cellBlocks = with std.blockTypes; [
+          # Software Delivery Lifecycle (Local Development Environment)
+          (devshells "envs")
+          (runnables "jobs")
+          # Software Delivery Lifecycle (Packaging Layers)
+          # For deeper context, please consult:
+          #   https://std.divnix.com/patterns/four-packaging-layers.html
+          (installables "packages" {ci.build = true;})
+          (runnables "operables")
+          (containers "oci-images" {ci.publish = true;})
+          (kubectl "deployments" {
+            ci.diff = true;
+            ci.apply = true;
+          })
+        ];
+      };
     };
 }

flake.nix

@@ -14,7 +14,7 @@ for i in $(ls ./src); do
   fi
 done
 
-for i in Http/schema.json Program/services/openApi.json ; do
+for i in Http/schema.json Program/services/openApi.json; do
   cp ./src/$i ./dist/cjs/$i
   # cp ./src/$i ./dist/esm/$i
 done

packages/cardano-services/copy-assets.sh

@@ -25,8 +25,8 @@ TEST1="yarn workspace @cardano-sdk/e2e test:wallet"
 TEST2="yarn workspace @cardano-sdk/e2e test:long-running delegation-rewards.test.ts"
 TEST3="yarn workspace @cardano-sdk/e2e test:local-network register-pool.test.ts"
 
-for test in "$TEST1" "$TEST2" "$TEST3" ; do
-  while ! $test ; do echo repeating... ; done
+for test in "$TEST1" "$TEST2" "$TEST3"; do
+  while ! $test; do echo repeating...; done
 done
 
 TL_LEVEL="${TL_LEVEL:=info}" node "$SCRIPT_DIR/mint-handles.js"

packages/cardano-services/test/jest-setup/rebuild-test-db.sh

@@ -4,13 +4,13 @@ Running these suites requires both a supported Ledger and Trezor device to be pl
 install udev rules, if running on Linux, which can be done by using the script documented in
 [Download and Install Ledger Live docs], and via the [Trezor Suite] UI.
 
-[Download and Install Ledger Live docs]: https://support.ledger.com/hc/en-us/articles/4404389606417-Download-and-install-Ledger-Live?docs=true
-[Trezor Suite]: https://trezor.io/trezor-suite
+[download and install ledger live docs]: https://support.ledger.com/hc/en-us/articles/4404389606417-Download-and-install-Ledger-Live?docs=true
+[trezor suite]: https://trezor.io/trezor-suite
 
-## Ledger HW Tests 
+## Ledger HW Tests
 
 `yarn test:hw:ledger`
 
-## Trezor HW Tests 
+## Trezor HW Tests
 
 `yarn test:hw:trezor`

packages/wallet/test/README.md

@@ -16,12 +16,10 @@ In this document, we will cover:
 
 - **Diagrams:** Discussing how these components interact within the context of a web browser extension with visual representations to aid in understanding the structure and flow of interactions.
 
-
 ## System Overview
 
 The **web-extension** package provides components for handling wallet management-related operations within the browser web extensions context. It brings together its own specialized components and further leverages additional elements from other SDK packages, notably the **ObservableWallet** interface from the 'wallet' package and the **Witnesser** interface from the 'key-management’ package.
 
-
 ### Components from the web-extension Package
 
 - **WalletManager:** Manages the lifecycle of ObservableWallets, including activation and deactivation, and is responsible for creating Witnesser instances.
@@ -52,7 +50,6 @@ In-memory key agents could technically live in the service worker, but keeping t
 
 This arrangement also ensures a safer, isolated environment for user prompts and transaction confirmations. As thus, the components of the wallet-extension are distributed among the service worker and the UI script as follows:
 
-
 ![Location of instances within the web extension](img/fig1.png)
 
 ## Component Descriptions
@@ -65,7 +62,6 @@ In essence, the **SigningCoordinator** is responsible for managing the signing o
 
 The **SigningCoordinator** also offers flexibility in handling different wallet types, such as InMemory, Ledger, and Trezor wallets. This flexibility is crucial for a web extension that aims to support a wide range of user preferences and hardware capabilities.
 
-
 ### WalletManager
 
 The **WalletManager** is responsible for orchestrating various wallet-related operations. It handles the lifecycle of wallets, including their creation, initialization, activation, deactivation, and switching of networks. These wallets are **ObservableWallet** instances, these instances provide real-time updates and states of the wallets, which include balance tracking, transaction histories, and more. The **WalletManager** effectively maintains a record of these instances, ensuring that the wallets are readily accessible.
@@ -92,7 +88,7 @@ The **ObservableWallet** is designed as a comprehensive interface that offers re
 
 ## Integration and Communication Flow
 
-The web-extension package components interact across the UI script and the background script (service worker) of the web extension environment. The scripts communicate using message passing, which allows both service worker and UI scripts to listen for each other's messages and respond on the same channel. 
+The web-extension package components interact across the UI script and the background script (service worker) of the web extension environment. The scripts communicate using message passing, which allows both service worker and UI scripts to listen for each other's messages and respond on the same channel.
 
 ## Bootstrapping
 
@@ -104,20 +100,19 @@ In the UI script the application creates the **SigningCoordinator** instance and
 
 ```javascript
 exposeApi(
-    {
-      api$: of(signingCoordinator),
-      baseChannel: signingCoordinatorApiChannel,
-      properties: signingCoordinatorApiProperties
-    },
-    dependencies
-  );
-
+  {
+    api$: of(signingCoordinator),
+    baseChannel: signingCoordinatorApiChannel,
+    properties: signingCoordinatorApiProperties
+  },
+  dependencies
+);
 ```
 
 This function exposes the **SigningCoordinator** to the code running in the service worker. Additionally, the UI script must subscribe to the **transactionWitnessRequest$** and **signDataRequest$** observables of the **SigningCoordinator** so it can handle signing requests that are initiated by the **ObservableWallet** that lives in the service worker. This is an example on how the web extension application could start the **SigningCoordinator**:
 
 ```javascript
-ui.ts
+ui.ts;
 
 // Instantiate the SigningCoordinator
 const signingCoordinator = new SigningCoordinator(
@@ -161,7 +156,7 @@ exposeSigningCoordinatorApi(
 The UI script also creates proxy objects for the exposed instances from the service worker of the **WalletRepository**, **WalletManager** and **ObservableWallet**:
 
 ```javascript
-ui.ts
+ui.ts;
 
 // Consume remote objects.
 const walletManager = consumeRemoteApi(
@@ -179,7 +174,6 @@ const wallet = consumeRemoteApi(
   { baseChannel: walletChannel(walletName), properties: observableWalletProperties },
   { logger, runtime }
 );
-
 ```
 
 The **consumeRemoteApi**, **walletManagerChannel**, **repositoryChannel** and **walletChannel** are all utility functions exported from the web-extension package.
@@ -258,7 +252,7 @@ This way the UI script can use this proxy object and subscribe to its observable
 
 ### WalletManager
 
-The **WalletManager**, residing in the service worker, is responsible for instantiating **ObservableWallets** configured to track the given credentials, network and account (if applicable). 
+The **WalletManager**, residing in the service worker, is responsible for instantiating **ObservableWallets** configured to track the given credentials, network and account (if applicable).
 
 When the UI scripts triggers a wallet switch, either by switching networks, accounts or even wallet credentials entirely, the **WalletManager** retrieves the requested wallet data from the **WalletRepository**, builds a new **Witnesser** using the **SigningCoordinator** (which is a proxy object from the UI script) and creates the new **ObservableWallet** instance, this new active wallet is emitted via the **activeWallet$** observable: