Merge pull request #128 from Green-Software-Foundation/rename-manifest-to-imp

Rename manifest to imp

Author: jmcook1186

.vscode/settings.json

@@ -0,0 +1,44 @@
+{
+    "grammarly.selectors": [
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/FAQ.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/reference/errors.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/users/how-to-compare-files-with-if-diff.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/reference/plugins.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/pipelines/sci.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/reference/cli.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/users/how-to-verify-files-with-if-check.md"
+        },
+        {
+            "language": "markdown",
+            "scheme": "file",
+            "pattern": "docs/users/how-to-use-the-explain-feature.md"
+        }
+    ]
+}

docs/FAQ.md

@@ -11,27 +11,27 @@ To contribute to these docs, you can raise pull requests against our [Github rep
 
 In general, you can consider any ticket on our [issue board](https://github.com/Green-Software-Foundation/if/issues) open for community contributions if it *does not* have the `core-only` tag. We tag suitable introductory issues as `good-first-issue` - these are great places to get started.
 
-## Is there any way to auto-generate manifest files? 
+## Is there any way to auto-generate IMP files? 
 
-Not really. We provide a command line tool called `if-env` which will generate a template manifest for you if you run it in an empty folder. We also provide a built-in feature called `mockObservations` that will autogenerate some input data for you (designed to generate dummy data for experimenting or scenario testing). There are also `importer` plugins that will pull data from files or APIs into IF manifests. However, we do not currently provide any tooling that will generate a full manifest file for you - we think humans in the loop are important for ensuring the nuances of your system are captured in the manifest and in general, we'd prefer not to automate that away. That said, there is potential for tooling that helps abstract out the more repetitive tasks associated with building large manifest files.
+Not really. We provide a command line tool called `if-env` which will generate a template IMP for you if you run it in an empty folder. We also provide a built-in feature called `mockObservations` that will autogenerate some input data for you (designed to generate dummy data for experimenting or scenario testing). There are also `importer` plugins that will pull data from files or APIs into IF IMPs. However, we do not currently provide any tooling that will generate a full IMP file for you - we think humans in the loop are important for ensuring the nuances of your system are captured in the IMP and in general, we'd prefer not to automate that away. That said, there is potential for tooling that helps abstract out the more repetitive tasks associated with building large IMP files.
 
-## Where do I get the data for my manifest file?
+## Where do I get the data for my IMP file?
 
-This is up to you! One of the strengths of the IF is that you can build manifests your way. We expect input data to come from an external file or an API in most cases, although you can manually add input data into your manifest too. People have built importer plugins for Azure's monitor API, Prometheus databases, CSV files, Datadog, and others. These importer plugins can be found on the [Explorer website](https://explorer.if.greensoftware.foundation).
+This is up to you! One of the strengths of the IF is that you can build IMPs your way. We expect input data to come from an external file or an API in most cases, although you can manually add input data into your IMP too. People have built importer plugins for Azure's monitor API, Prometheus databases, CSV files, Datadog, and others. These importer plugins can be found on the [Explorer website](https://explorer.if.greensoftware.foundation).
 
 ## What is your vision for the IF?
 
-The vision is to build a protocol that enables you to calculate the appropriate environmental impact for your application, whatever it is. We want to be an open communication standard - our dream is that an IF manifest is the primary way that people share the environmental impacts of their systems.
+The vision is to build a protocol that enables you to calculate the appropriate environmental impact for your application, whatever it is. We want to be an open communication standard - our dream is that an IF IMP is the primary way that people share the environmental impacts of their systems.
 
 Right now we consider our core functionality to be calculating software carbon intensity scores for software applications running in the cloud, but we have people using IF on-premise and even for supply chain modeling and other non-software applications. The idea is that we provide the minimal infrastructure required for you to build up different use cases using plugins.
 
 ## Is there a way to generate an audit/report along with a csv/yaml output?
 
-No - we see the manifest file and associated manifest as a new type of "executable audit". The IF itself does not generate any other form of report, although there is nothing stopping others from building out this functionality on top of IF.
+No - we see the IMP file and associated IMP as a new type of "executable audit". The IF itself does not generate any other form of report, although there is nothing stopping others from building out this functionality on top of IF.
 
 ## IF makes things transparent, but how can you fight against users inputting incorrect or misleading data?
 
-We can't really stop people providing fake data into a manifest file. We're very interested in ways we can verify that the computation was done correctly and provide public proofs, but without direct access to a user's systems we can never guarantee they are providing truthful data. This is not unique to IF - fraud is a problem across all industries.
+We can't really stop people providing fake data into an IMP file. We're very interested in ways we can verify that the computation was done correctly and provide public proofs, but without direct access to a user's systems we can never guarantee they are providing truthful data. This is not unique to IF - fraud is a problem across all industries.
 
 ## Is it planned to make the IF more user-friendly or also more usable for less technical people?
 
@@ -47,7 +47,7 @@ No we haven't - we've been focussing on capturing impacts of individual applicat
 
 ## Are you planning to support e.g. for PaaS, IaaS, alternative cloud providers...etc?
 
-We are focused on building out the low-level core infrastructure so that users can apply IF to any use case. We do not currently intend to build out support for any specific service. We want users to build plugins and publish them to the [Explorer](https://explorer.if.greensoftware.foundation) and share manifests to support individual use cases.
+We are focused on building out the low-level core infrastructure so that users can apply IF to any use case. We do not currently intend to build out support for any specific service. We want users to build plugins and publish them to the [Explorer](https://explorer.if.greensoftware.foundation) and share IMPs to support individual use cases.
 
 
 ## What is on your roadmap?

docs/developers/how-to-build-plugins.md

@@ -9,7 +9,7 @@ To help developers write Typescript plugins to integrate easily into IF, we prov
 
 - create a Typescript file that implements the `PluginFactory` from [`if-core`](https://github.com/Green-Software-Foundation/if-core)
 - install the plugin
-- initialize and invoke the plugin in your manifest file
+- initialize and invoke the plugin in your IMP file
 
 ## Step 1: Use our template repository
 
@@ -59,7 +59,7 @@ The inner function returned by the `PluginFactory` handles the following paramet
 
 ### Config
 
-The `config` object is passed as an argument to your plugin and can be handled as shown in the example above. The structure of the config depends on what is defined in the manifest file. For example, the `Sci` plugin has access to `input-parameters` and `output-parameter` fields in its global configuration, as defined in the `Initialize` block of the manifest file:
+The `config` object is passed as an argument to your plugin and can be handled as shown in the example above. The structure of the config depends on what is defined in the IMP file. For example, the `Sci` plugin has access to `input-parameters` and `output-parameter` fields in its global configuration, as defined in the `Initialize` block of the IMP file:
 
 ```yaml
 initialize:
@@ -74,7 +74,7 @@ initialize:
 
 ### Parameter metadata
 
-The `parameter-metadata` is passed as an argument to the plugin as the config. It contains information about the `description`, `unit` and `aggregation-method` of the parameters of the inputs and outputs that defined in the manifest.
+The `parameter-metadata` is passed as an argument to the plugin as the config. It contains information about the `description`, `unit` and `aggregation-method` of the parameters of the inputs and outputs that defined in the IMP.
 
 ```yaml
 initialize:
@@ -234,7 +234,7 @@ Additional Notes
 
 - `Implement`: You should implement `implementation` function. It should contains the primary logic to generate outputs.
 - `Validation`: You should define appropriate `zod` schemas or validation functions for both config and inputs. This ensures that invalid data is caught early and handled appropriately.
-- `Arithmetic Expressions`: By including configuration, input, and output parameters of the plugin in the `allowArithmeticExpressions` array, you enable dynamic evaluation of mathematical expressions within parameter values. This eliminates the need for manual pre-calculation and allows basic mathematical operations to be embedded directly within parameter values in manifest files. More details [here.](../reference/features.md)
+- `Arithmetic Expressions`: By including configuration, input, and output parameters of the plugin in the `allowArithmeticExpressions` array, you enable dynamic evaluation of mathematical expressions within parameter values. This eliminates the need for manual pre-calculation and allows basic mathematical operations to be embedded directly within parameter values in IMP files. More details [here.](../reference/features.md)
 - `Mapping`: Ensure your plugin correctly handles the mapping of parameters. This is essential when working with dynamic input and output configurations.
 
 ## Step 3: Install your plugin
@@ -261,7 +261,7 @@ npm link new-plugin
 
 replacing `new-plugin` with your plugin name as defined in the plugin's `package.json`. If you are not sure, the name can be checked by running `npm ls -g --depth=0 --link=true`.
 
-Your plugin is now ready to be run in IF. All that remains is to add your plugin to your manifest file. This means adding it to the `initialize block` and adding it to the component pipelines where you want your plugin to be executed. For example, an `initilize` block might look as follows:
+Your plugin is now ready to be run in IF. All that remains is to add your plugin to your IMP file. This means adding it to the `initialize block` and adding it to the component pipelines where you want your plugin to be executed. For example, an `initilize` block might look as follows:
 
 ```yaml
 initialize:
@@ -273,10 +273,10 @@ initialize:
         something: true
 ```
 
-Run your manifest uisng
+Run your IMP uisng
 
 ```sh
-npm run if-run -- --manifest <path-to-manifest>
+npm run if-run -- --manifest <path-to-imp>
 ```
 
 If you have to link more than one local plugin, for example to test your plugin in a pipeline, you can do so with
@@ -289,15 +289,15 @@ This will create an entry like `"new-plugin": "file:path/to/your/plugin"` in the
 
 ## Step 5: Publishing your plugin
 
-Now you have run your plugin locally and you are happy with how it works, you can make it public by publishing it to a public Github repository. Now all you have to do to use it in a manifest file is `npm install` it and pass the path to the Github repository in the plugin `initialize` block.
+Now you have run your plugin locally and you are happy with how it works, you can make it public by publishing it to a public Github repository. Now all you have to do to use it in an IMP file is `npm install` it and pass the path to the Github repository in the plugin `initialize` block.
 
 For example, for a plugin saved in `github.com/my-repo/new-plugin` you can do the following:
 
 ```
 npm install https://github.com/my-repo/new-plugin
 ```
 
-Then, in your manifest file, provide the path in the plugin instantiation. You also need to specify which function the plugin instantiates. Let's say you are using the `Sci` plugin from the example above:
+Then, in your IMP file, provide the path in the plugin instantiation. You also need to specify which function the plugin instantiates. Let's say you are using the `Sci` plugin from the example above:
 
 ```yaml
 name: plugin-demo
@@ -314,12 +314,12 @@ tree:
       inputs:
 ```
 
-Now, when you run the manifest file, it will load the plugin automatically.
+Now, when you run the IMP file, it will load the plugin automatically.
 
 You can run this using the globally installed IF as follows:
 
 ```sh
-if-run --manifest <path-to-my-manifest>
+if-run --manifest <path-to-my-imp>
 ```
 
 ## Summary of steps
@@ -328,7 +328,7 @@ if-run --manifest <path-to-my-manifest>
 - Add your plugin code to `index.ts`
 - Build and link the plugin using `npm run build && npm link`
 - Load your plugin into `if` using `npm link`
-- Initialize your plugin and add it to a pipeline in your manifest file.
+- Initialize your plugin and add it to a pipeline in your IMP file.
 - Publish your plugin to Github
 
 You should also create unit tests for your plugin to demonstrate correct execution and handling of corner cases.

docs/developers/how-to-create-exhaust-script.md

@@ -7,7 +7,7 @@ sidebar-position: 6
 The `IF` framework outputs data in `yaml` format. Any other output formats require a separate script that takes the yaml output data and processes it. We provide [`if-csv`](../users/how-to-export-csv-file-with-if-csv.md) for outputting data in `csv` format bundled with IF. For any other format, you need to write an exhaust script.
 This guide will help you create your own exhaust script.
 
-In this example, we'll create a script that executes the manifest and outputs the data in `json` format.
+In this example, we'll create a script that executes the IMP and outputs the data in `json` format.
 
 ```ts
 const IfJson = async () => {
@@ -42,4 +42,4 @@ To add this script to your package.json, include the following entry in the scri
 }
 ```
 
-This setup ensures that your script will execute the manifest and output the data in JSON format.
+This setup ensures that your script will execute the IMP and output the data in JSON format.

docs/developers/how-to-submit-plugins.md

@@ -30,7 +30,7 @@ Your plugin documentation should include the following information:
 - A description of any environment setup such as credentials in environment variables, etc. (REQUIRED)
 - Installation instructions (REQUIRED)
 - A written description of the plugin behaviour (REQUIRED)
-- A demo manifest that executes the plugin correctly without errors (REQUIRED)
+- A demo IMP that executes the plugin correctly without errors (REQUIRED)
 - A link to your unit tests 
 - A list of errors that your plugin can raise, the behaviours that cause them and potential remedies.
 - A reference list of any publications or other material supporting the approach you have taken in your plugin.

docs/intro.md

@@ -10,7 +10,7 @@ sidebar_position: 1
 
 Impact Framework (IF) aims to make the environmental impacts of software easier to calculate **and** share.
 
-IF allows you to calculate the environmental impacts, such as carbon, of your software applications without writing any code. All you have to do is write a simple **manifest file** and IF handles the rest.
+IF allows you to calculate the environmental impacts, such as carbon, of your software applications without writing any code. All you have to do is write a simple **IMP file** and IF handles the rest.
 
 The project is entirely open source and composability is a core design principle - we want you to be able to create your own plugins and plug them in to our framework, or pick from a broad universe of open source plugins created by others.
 

docs/major-concepts/aggregation.md

@@ -22,7 +22,7 @@ Assuming the aggregation method is `sum`, the parent would receive an aggregated
 
 ## Configuration
 
-`Aggregate` is a built-in feature of the IF. This means you do not need to initialize it along with the plugins you are using in your pipeline. All you need to do is to add a small piece of config to your manifest file.
+`Aggregate` is a built-in feature of the IF. This means you do not need to initialize it along with the plugins you are using in your pipeline. All you need to do is to add a small piece of config to your IMP file.
 
 The `aggregate` config looks as follows:
 
@@ -50,7 +50,7 @@ Similarly, some values are proportions or percentages. In these cases, the right
 
 ## Aggregation outputs
 
-The aggregation process adds new output data to your manifest file. The two types of aggregation add different outputs. The horizontal (time-series) aggregation adds a new field called `aggregated` to each node whose time series has been aggregated. In the `aggregated` block, you will find the aggregated value for each of the aggregation metrics defined in the aggregation config.
+The aggregation process adds new output data to your IMP file. The two types of aggregation add different outputs. The horizontal (time-series) aggregation adds a new field called `aggregated` to each node whose time series has been aggregated. In the `aggregated` block, you will find the aggregated value for each of the aggregation metrics defined in the aggregation config.
 
 The vertical aggregation adds a new array of output observations. These are simply named `outputs` and they always contain a timestamp and duration along with the aggregated metrics for each timestep.