From ba522eeccd009a6d39f9fe0cf3562c007a7693eb Mon Sep 17 00:00:00 2001 From: toyeshhm Date: Mon, 7 Sep 2026 10:01:38 -0500 Subject: [PATCH] Fix broken localhost URL in modular LLM stack example and doc typos The Weaviate invocation in examples/LLM_Workflows/modular_llm_stack/README.md pointed at http://locahost:8080/, which fails to resolve when copied. The kedro example README referenced a noteboks/ directory that does not exist (the directory is notebooks/). Also corrects spelling across READMEs, docs, and writeups (repository, initialization, queries, overridden, module, pipeline, localhost, parallelism, dependencies, package, etc.), two doubled words, and won't/every time. --- .github/PULL_REQUEST_TEMPLATE.md | 2 +- contrib/README.md | 4 ++-- .../contrib/user/elijahbenizzy/caption_images/README.md | 2 +- .../hamilton/contrib/user/zilto/llm_generate_code/README.md | 2 +- .../hamilton/contrib/user/zilto/nixtla_mlforecast/README.md | 2 +- docs/how-tos/pre-commit-hooks.md | 2 +- docs/how-tos/use-in-jupyter-notebook.md | 2 +- docs/integrations/fastapi.md | 2 +- examples/LLM_Workflows/NER_Example/README.md | 2 +- examples/LLM_Workflows/langchain_comparison/README.md | 2 +- examples/LLM_Workflows/modular_llm_stack/README.md | 2 +- examples/LLM_Workflows/pdf_summarizer/README.md | 2 +- examples/async/README.md | 2 +- examples/cli/README.md | 2 +- examples/dagster/dagster_code/README.md | 2 +- examples/dagster/hamilton_code/README.md | 2 +- examples/dlt/slack/README.md | 2 +- .../feature_engineering_multiple_contexts/README.md | 4 ++-- .../scenario_1/README.md | 6 +++--- .../scenario_2/README.md | 4 ++-- examples/hamilton-tutorials/mpg-translation/README.md | 2 +- examples/kedro/hamilton-code/README.md | 2 +- examples/parallelism/graceful_running/README.md | 2 +- examples/ray/README.md | 2 +- examples/spark/pyspark/README.md | 2 +- hamilton/plugins/README.md | 2 +- ui/README.md | 2 +- writeups/decorators.md | 4 ++-- 28 files changed, 34 insertions(+), 34 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 048d2f058..0c4b87311 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -2,7 +2,7 @@ --- PR TEMPLATE INSTRUCTIONS (1) --- -Looking to submit a Apache Hamilton Dataflow to the apache-hamilton-contrib module? If so go the the `Preview` tab and select the appropriate sub-template: +Looking to submit a Apache Hamilton Dataflow to the apache-hamilton-contrib module? If so go to the `Preview` tab and select the appropriate sub-template: * [apache-hamilton-contrib template](?expand=1&template=HAMILTON_CONTRIB_PR_TEMPLATE.md) Else, if not, please remove this block of text. diff --git a/contrib/README.md b/contrib/README.md index fe6d0240e..e04a70f06 100644 --- a/contrib/README.md +++ b/contrib/README.md @@ -32,7 +32,7 @@ ready to be used in your own projects. They are user-contributed and maintained, the goal of making it easier for you to get started with Apache Hamilton. We expect this collection to grow over time, so check back often! As dataflows become mature we -will move them into the official sub-package of the respository and become maintained by the +will move them into the official sub-package of the repository and become maintained by the Apache Hamilton team. ### Usage @@ -141,7 +141,7 @@ Standards: To get started with development, you'll want to first fork the hamilton repository from the github UI. -Then, clone it locally and install the package in editable mode, ensuring you install any dependencies required for the initilization script +Then, clone it locally and install the package in editable mode, ensuring you install any dependencies required for the initialization script ```bash cd hamilton # Your fork pip install -e "./contrib[contribute]" # Note that this package lives under the `contrib` folder diff --git a/contrib/hamilton/contrib/user/elijahbenizzy/caption_images/README.md b/contrib/hamilton/contrib/user/elijahbenizzy/caption_images/README.md index 691d9d779..eae42cf23 100644 --- a/contrib/hamilton/contrib/user/elijahbenizzy/caption_images/README.md +++ b/contrib/hamilton/contrib/user/elijahbenizzy/caption_images/README.md @@ -46,7 +46,7 @@ This also accepts the following overrides: Note that this has two modes: -1. (`include_embeddings=False`, or not specified) Just quries the caption for the image. You can request `generated_caption`, which will give embeddings for the caption. +1. (`include_embeddings=False`, or not specified) Just queries the caption for the image. You can request `generated_caption`, which will give embeddings for the caption. 2. (`include_embeddings=True`): also gets the caption for the image, and the embeddings the caption. This requires `caption_embeddings` to be one of the variables called. If you want all the metadata about this run wrapped up in a dictionary (say, to save externally), you can request `metadata` which will return a dict with the following keys: diff --git a/contrib/hamilton/contrib/user/zilto/llm_generate_code/README.md b/contrib/hamilton/contrib/user/zilto/llm_generate_code/README.md index ca61d4f0a..806d212b7 100644 --- a/contrib/hamilton/contrib/user/zilto/llm_generate_code/README.md +++ b/contrib/hamilton/contrib/user/zilto/llm_generate_code/README.md @@ -45,7 +45,7 @@ This module doesn't receive configurations. ### Inputs - `query`: The query for which you want code generated. - `api_key`: Set the OpenAI API key to use. If None, read the environment variable `OPENAI_API_KEY` -- `code_language`: Set the code language to generate the reponse in. Defaults to `python` +- `code_language`: Set the code language to generate the response in. Defaults to `python` ### Overrides - `prompt_template_to_generate_code`: Create a new prompt template with the fields `query` and `code_language`. diff --git a/contrib/hamilton/contrib/user/zilto/nixtla_mlforecast/README.md b/contrib/hamilton/contrib/user/zilto/nixtla_mlforecast/README.md index 884852108..0cb5be003 100644 --- a/contrib/hamilton/contrib/user/zilto/nixtla_mlforecast/README.md +++ b/contrib/hamilton/contrib/user/zilto/nixtla_mlforecast/README.md @@ -37,7 +37,7 @@ This module doesn't receive configurations. ## Overrides - `base_models`: Create a list of sklearn-compatible models to fit and evaluate ([docs](https://nixtla.github.io/statsforecast/src/core/models.html)) -- `lag_transforms` and `date_features`: Should be overriden to pass values relevant to your dataset +- `lag_transforms` and `date_features`: Should be overridden to pass values relevant to your dataset - `evaluation_metrics`: Set the list of Nixtla-compatible metrics to use during cross-validation ([examples](https://github.com/Nixtla/utilsforecast/blob/main/utilsforecast/losses.py)) diff --git a/docs/how-tos/pre-commit-hooks.md b/docs/how-tos/pre-commit-hooks.md index dc36ab269..ac3c4db1c 100644 --- a/docs/how-tos/pre-commit-hooks.md +++ b/docs/how-tos/pre-commit-hooks.md @@ -25,7 +25,7 @@ This page gives an introduction to pre-commit hooks and how to use custom hooks ## What are pre-commit hooks? A pre-commit hook is a script or command that's executed automatically before making a commit. The goal of these hooks is to standardize code formatting and catch erroneous code before being committed. For example, popular hooks include ensuring files have no syntax errors, sorting imports, and normalizing line breaks. -Note that it's different from testing, which focuses on the behavior of the code. You can think of pre-commit hooks as checks and formatting you would do everytime you save a file. +Note that it's different from testing, which focuses on the behavior of the code. You can think of pre-commit hooks as checks and formatting you would do every time you save a file. ## Add pre-commit hooks to your project Hooks are a mechanism of the `git` version control system. You can find your project's hooks under the `.git/hooks` directory (it might be hidden by default). There should be many files with the `.sample` extension that serve as example scripts. diff --git a/docs/how-tos/use-in-jupyter-notebook.md b/docs/how-tos/use-in-jupyter-notebook.md index 5b48f39a6..b0c15a94e 100644 --- a/docs/how-tos/use-in-jupyter-notebook.md +++ b/docs/how-tos/use-in-jupyter-notebook.md @@ -108,7 +108,7 @@ def log_avg_3wk_spend(avg_3wk_spend: pd.Series) -> pd.Series: We then have to create a "temporary python module" to house it in. We do this by importing `ad_hoc_utils` and then calling the `create_temporary_module` function, passing in the functions we want, and providing a name for the module we're creating. ```python -# Step 2 - create a temporary modeul to house all notebook functions +# Step 2 - create a temporary module to house all notebook functions from hamilton import ad_hoc_utils temp_module = ad_hoc_utils.create_temporary_module( log_avg_3wk_spend, module_name='function_example') diff --git a/docs/integrations/fastapi.md b/docs/integrations/fastapi.md index c56561f84..f6e11cea6 100644 --- a/docs/integrations/fastapi.md +++ b/docs/integrations/fastapi.md @@ -57,7 +57,7 @@ FastAPI already does a great job at automating API documentation by integrating ## Apache Hamilton + FastAPI Adding Apache Hamilton to your FastAPI server can provide a better separation between the dataflow and the API endpoints. Each endpoint can use `Driver.execute()` to request variables and wrap results into an HTTP response. Then, data transformations and interactions with resources (e.g., database, web service) are curated into standalone Python modules and decoupled from the server code. -Since Apache Hamilton dataflows will run the same way inside or outside FastAPI, you can write simpler unit tests for Hamilton functions without defining a mock server and client. Additionnally, visualizations for the defined Apache Hamilton dataflows can be added to the FastAPI [Swagger UI documentation](https://fastapi.tiangolo.com/features/#automatic-docs). They will remain in sync with the API behavior because they are generated from the code. +Since Apache Hamilton dataflows will run the same way inside or outside FastAPI, you can write simpler unit tests for Hamilton functions without defining a mock server and client. Additionally, visualizations for the defined Apache Hamilton dataflows can be added to the FastAPI [Swagger UI documentation](https://fastapi.tiangolo.com/features/#automatic-docs). They will remain in sync with the API behavior because they are generated from the code. ### Example In this example, we'll build a backend for a PDF summarizer application. diff --git a/examples/LLM_Workflows/NER_Example/README.md b/examples/LLM_Workflows/NER_Example/README.md index 2fabd3879..c70c2c734 100644 --- a/examples/LLM_Workflows/NER_Example/README.md +++ b/examples/LLM_Workflows/NER_Example/README.md @@ -27,7 +27,7 @@ this can be used when trying to find the most relevant text to pass to an LLM in context. The pipeline we create can be seen in the image below. -![pipeine](ner_extraction_pipeline.png) +![pipeline](ner_extraction_pipeline.png) To run this in a notebook: diff --git a/examples/LLM_Workflows/langchain_comparison/README.md b/examples/LLM_Workflows/langchain_comparison/README.md index 0188329c1..98578efb6 100644 --- a/examples/LLM_Workflows/langchain_comparison/README.md +++ b/examples/LLM_Workflows/langchain_comparison/README.md @@ -34,7 +34,7 @@ Files prefixed with `hamilton_` are the Apache Hamilton equivalent of the exampl As you browse the files you'll see that: 1. LangChain's focus is on hiding details and making code terse. -2. Apache Hamilton's focus instead is on making code more readable, maintainable, and importantly customizeable. +2. Apache Hamilton's focus instead is on making code more readable, maintainable, and importantly customizable. ## Implications Don't be surprised that Apache Hamilton's code is "longer" - that's by design. There is diff --git a/examples/LLM_Workflows/modular_llm_stack/README.md b/examples/LLM_Workflows/modular_llm_stack/README.md index a2aae5e2f..bad8c166e 100644 --- a/examples/LLM_Workflows/modular_llm_stack/README.md +++ b/examples/LLM_Workflows/modular_llm_stack/README.md @@ -72,7 +72,7 @@ To change embedding service, you can use the following: To change vector database you need to pass a JSON config argument: - LanceDB: `--vector_db=lancedb --vector_db_config='{"uri": "data/lancedb"}'` -- Weaviate: `--vector_db=weaviate --vector_db_config='{"url": "http://locahost:8080/"}'` +- Weaviate: `--vector_db=weaviate --vector_db_config='{"url": "http://localhost:8080/"}'` - Pinecone: `--vector_db=pinecone --vector_db_config='{"environment": "ENVIRONMENT", "api_key": "API_KEY"}'` - Marqo: `--vector_db=marqo --vector_db_config='{"url":"http://localhost:8882"}' --other_input_kwargs '{"index_name":"hamilton"}'` - Qdrant: `--vector_db=qdrant --vector_db_config='{"url":"http://localhost:6333"}'` diff --git a/examples/LLM_Workflows/pdf_summarizer/README.md b/examples/LLM_Workflows/pdf_summarizer/README.md index f760b30ae..a413235d8 100644 --- a/examples/LLM_Workflows/pdf_summarizer/README.md +++ b/examples/LLM_Workflows/pdf_summarizer/README.md @@ -18,7 +18,7 @@ under the License. --> # (Yet another) LLM PDF Summarizer 📝 -Here's an extensible and production-ready PDF summarizer that you can run anywhere! The frontend uses streamlit, which communicates with a FastAPI backend powered by Apache Hamilton. You give it a PDF file via the browser app and it returns you a text summary using the OpenAI API. If you want, you skip the browser inteface and directly access the `/summarize` endpoint with your document! Everything is containerized using Docker, so you should be able to run it where you please 🏃. +Here's an extensible and production-ready PDF summarizer that you can run anywhere! The frontend uses streamlit, which communicates with a FastAPI backend powered by Apache Hamilton. You give it a PDF file via the browser app and it returns you a text summary using the OpenAI API. If you want, you skip the browser interface and directly access the `/summarize` endpoint with your document! Everything is containerized using Docker, so you should be able to run it where you please 🏃. ## Why build this project? This project shows how easy it is to productionize Apache Hamilton. Its function-centric declarative approach makes the code easy to read and extend. We invite you to clone the repo and customize to your needs! We are happy to help you via [Slack](https://hamilton-opensource.slack.com/join/shared_invite/zt-1bjs72asx-wcUTgH7q7QX1igiQ5bbdcg) and are excited to see what you build 😁 diff --git a/examples/async/README.md b/examples/async/README.md index ecafaa4ee..d84302f17 100644 --- a/examples/async/README.md +++ b/examples/async/README.md @@ -70,7 +70,7 @@ pip install apache-hamilton[ui] hamilton ui ``` -This assumes a project (1) exists -- if you want a different one you can go the the UI and create one and/or set it in the code. +This assumes a project (1) exists -- if you want a different one you can go to the UI and create one and/or set it in the code. ## How it works diff --git a/examples/cli/README.md b/examples/cli/README.md index e11aa7eb3..6dd2842bb 100644 --- a/examples/cli/README.md +++ b/examples/cli/README.md @@ -37,7 +37,7 @@ Test the installation with - `validate`: calls `Driver.validate_execution()` for a set of `inputs` and `overrides` passed through the `--context` option. - `view`: calls `dr.display_all_functions()` on the built `Driver` - `version`: generates node hashes based on their source code, and a dataflow hash from the collection of node hashes. -- `diff`: get a diff of added/deleted/edited nodes between the current version of Python modules and another git reference (`default=HEAD`, i.e., the last commited version). You can get a visualization of the diffs +- `diff`: get a diff of added/deleted/edited nodes between the current version of Python modules and another git reference (`default=HEAD`, i.e., the last committed version). You can get a visualization of the diffs ## Options - all commands receive `MODULES` which is a list of path to Python modules to assembled as a single dataflow diff --git a/examples/dagster/dagster_code/README.md b/examples/dagster/dagster_code/README.md index ad895a871..d3db3ca94 100644 --- a/examples/dagster/dagster_code/README.md +++ b/examples/dagster/dagster_code/README.md @@ -26,7 +26,7 @@ This project is adapted from the official [Dagster tutorial](https://docs.dagste - `pyproject.toml` and `setup.py` define how to install the `tutorial/` Dagster project. - `tutorial/assets.py` defines the data assets to compute and materialize. - `tutorial/__init__.py` register the data assets, jobs, and resources for the orchestrator. -- `tutorial/resources/` contains informations to connect to external resources and API. +- `tutorial/resources/` contains information to connect to external resources and API. ## Instructions 1. Install the Dagster project as a Python module diff --git a/examples/dagster/hamilton_code/README.md b/examples/dagster/hamilton_code/README.md index 40e30785d..60877d2d4 100644 --- a/examples/dagster/hamilton_code/README.md +++ b/examples/dagster/hamilton_code/README.md @@ -29,7 +29,7 @@ The Apache Hamilton refactor achieves the same data transformations. The project - `run.py` contains the "driver code" to load and execute the dataflow (equivalent to Dagster `tutorial/__init__.py`). - `notebook.ipynb` contains code to execute the dataflow (similar code to `run.py`), but allows for an interactive exploration of results. -The directory also include `mock_api.py` which simulates a `ressource` in the Dagster tutorial, and `dataflow.png` which is an artifact generated by the Apache Hamilton `Driver`. +The directory also include `mock_api.py` which simulates a `resource` in the Dagster tutorial, and `dataflow.png` which is an artifact generated by the Apache Hamilton `Driver`. ## Instructions 1. Run the code diff --git a/examples/dlt/slack/README.md b/examples/dlt/slack/README.md index 19e623db0..ae34a821b 100644 --- a/examples/dlt/slack/README.md +++ b/examples/dlt/slack/README.md @@ -95,7 +95,7 @@ source = slack_source() source.access_logs.selected = True ``` -The conversations resource can be used to load the list of available conversations and will allways bring all +The conversations resource can be used to load the list of available conversations and will always bring all the available conversations. The history resource can be used to load the history of a conversation. By default all the conversations will be diff --git a/examples/feature_engineering/feature_engineering_multiple_contexts/README.md b/examples/feature_engineering/feature_engineering_multiple_contexts/README.md index 116b92ad0..9aff865f7 100644 --- a/examples/feature_engineering/feature_engineering_multiple_contexts/README.md +++ b/examples/feature_engineering/feature_engineering_multiple_contexts/README.md @@ -64,7 +64,7 @@ Not having lineage or visibility into what data is being used for what purpose c ## Deployment: Offline vs online vs streaming needs -This is a big topic. We wont do it justice here, but let's try to give a brief overview of two main problems: +This is a big topic. We won't do it justice here, but let's try to give a brief overview of two main problems: (1) There are a lot of different deployment needs when you get something to production. For example, you might want to: - run a batch job to generate features for a model @@ -151,7 +151,7 @@ Jump into each directory and read the README, it'll explain how the example is s # What are extensions/uses not shown here but we know you can do them Here are two ideas that come to mind: -1. Streaming settings. Given the examples, it should be clear how to make it possbile to use Apache Hamilton in a streaming setting. +1. Streaming settings. Given the examples, it should be clear how to make it possible to use Apache Hamilton in a streaming setting. 2. How to ask Apache Hamilton what features are needed as input to know what to request from the feature store. With tags, and querying the DAG at the start of the app, you could dynamically ask Apache Hamilton what's required and then only go to the feature store for that data. If this type of example would be of interest, let us know. diff --git a/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_1/README.md b/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_1/README.md index b8666b1be..9cf19e2b8 100644 --- a/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_1/README.md +++ b/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_1/README.md @@ -55,10 +55,10 @@ dataquality checks using Pandera. Important not, there are two aggregations features defined: `age_mean` and `age_std_dev`, that are computed on the `age` column. These make sense to compute in an offline setting as you have all the data, but in an online setting where -you'd be performing inference, that doesn't makse sense. So for the online case, these computations be "overridden" in +you'd be performing inference, that doesn't make sense. So for the online case, these computations be "overridden" in `fastapi_server.py` with the values that were computed in the offline setting that you have stored (as mentioned above and below it's up to you how to store them/sync them). The nice thing in Apache Hamilton is that we can also "tag" these two -feature transforms with information to indicate to someone reading the code, that they should be overriden in the +feature transforms with information to indicate to someone reading the code, that they should be overridden in the online feature computation context. ## etl.py @@ -75,7 +75,7 @@ Note, you need to store `age_mean` and ## named_model_feature_sets.py Rather than hardcoding what features the model should have in two places, we define -it in a single place and import it where needed; this is simple if you can share the code eaisly. +it in a single place and import it where needed; this is simple if you can share the code easily. However, this is something you'll have to determine how to best do in your set up. There are many ways to do this, come ask in the [slack channel](https://join.slack.com/t/hamilton-opensource/shared_invite/zt-2niepkra8-DGKGf_tTYhXuJWBTXtIs4g) if you need help. diff --git a/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_2/README.md b/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_2/README.md index 6d3f7c6a1..03f993d85 100644 --- a/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_2/README.md +++ b/examples/feature_engineering/feature_engineering_multiple_contexts/scenario_2/README.md @@ -49,7 +49,7 @@ dataquality checks using Pandera. Important not, there are two aggregations features defined: `age_mean` and `age_std_dev`, that are computed on the `age` column. These make sense to compute in an offline setting as you have all the data, but in an online setting where -you'd be performing inference, that doesn't makse sense. So for the online case, in this example, they are "omitted" from +you'd be performing inference, that doesn't make sense. So for the online case, in this example, they are "omitted" from being nodes in the online context via `@config.when_not_in`. Instead, they are populated via the `online_loader.py` which goes to the feature store for them. `fastapi_server.py` then is a little simpler than in Scenario (1), as it just delegates all work to Apache Hamilton for getting features. @@ -72,7 +72,7 @@ Note, `age_mean` and `age_std_dev` are pushed to the feature store in this examp ## named_model_feature_sets.py Rather than hardcoding what features the model should have in two places, we define -it in a single place and import it where needed; this is simple if you can share the code eaisly. +it in a single place and import it where needed; this is simple if you can share the code easily. However, this is something you'll have to determine how to best do in your set up. There are many ways to do this, come ask in the [slack channel](https://join.slack.com/t/hamilton-opensource/shared_invite/zt-2niepkra8-DGKGf_tTYhXuJWBTXtIs4g) if you need help. diff --git a/examples/hamilton-tutorials/mpg-translation/README.md b/examples/hamilton-tutorials/mpg-translation/README.md index a01432cc7..6d80f0794 100644 --- a/examples/hamilton-tutorials/mpg-translation/README.md +++ b/examples/hamilton-tutorials/mpg-translation/README.md @@ -38,7 +38,7 @@ To get set up: 2. Go into the `examples/hamilton-tutorials/mpg-translation` directory. 2. Install Apache Hamilton. `pip install - requirements.txt` 3. Write code. -4. Excute via notebook or command line. +4. Execute via notebook or command line. Or run it in Google Colab: diff --git a/examples/kedro/hamilton-code/README.md b/examples/kedro/hamilton-code/README.md index 63f24a88b..d80c70d68 100644 --- a/examples/kedro/hamilton-code/README.md +++ b/examples/kedro/hamilton-code/README.md @@ -26,7 +26,7 @@ under the License. The Apache Hamilton refactor is composed of a few files: - `data_processing.py` and `data_science.py` contains regular Python functions to define the Apache Hamilton dataflow. This is equivalent to Kedro's `pipeline.py` **and** `nodes.py` files. - `run.py` contains the "driver code" to load and execute the dataflow. There's no direct equivalent in the Kedro tutorial since it prefers using the CLI for execution. -- `noteboks/interactive.ipynb` contains the "driver code", similar to `run.py`, but uses [Apache Hamilton Jupyter Magics](https://hamilton.apache.org/how-tos/use-in-jupyter-notebook/#use-hamilton-jupyter-magic) to define the dataflow interactily in a notebook. +- `notebooks/interactive.ipynb` contains the "driver code", similar to `run.py`, but uses [Apache Hamilton Jupyter Magics](https://hamilton.apache.org/how-tos/use-in-jupyter-notebook/#use-hamilton-jupyter-magic) to define the dataflow interactively in a notebook. - `tests/test_dataflow.py` includes tests equivalent to `tests/pipelines/data_science/test_pipeline.py` in the Kedro code. ## Instructions diff --git a/examples/parallelism/graceful_running/README.md b/examples/parallelism/graceful_running/README.md index 5215433a6..c854071a2 100644 --- a/examples/parallelism/graceful_running/README.md +++ b/examples/parallelism/graceful_running/README.md @@ -23,7 +23,7 @@ under the License. This is a simple example of using the `GracefulErrorAdapter` in a parallelism example, where we might expect some component of an analysis to fail, but we'd still like to get as much data back as we can. -This example divides a large dataframe into smaller frames, and runs the same analysis on each of those frames. It then gathers the results at the end into a single frame. Any errors inside the paralellism block do not halt the total operation of the driver. +This example divides a large dataframe into smaller frames, and runs the same analysis on each of those frames. It then gathers the results at the end into a single frame. Any errors inside the parallelism block do not halt the total operation of the driver. The user can define custom data splitting functions to process in the same sub-dag. In some ways, this is an example of how to do `@subdag` with `Parallelizable`. diff --git a/examples/ray/README.md b/examples/ray/README.md index 71bc3d9a7..af4e7a106 100644 --- a/examples/ray/README.md +++ b/examples/ray/README.md @@ -31,5 +31,5 @@ scaling Apache Hamilton on Ray, where `@ray.remote` is injected around each Apache Hamilton function. ## creating tasks -For [this paralle task approach](https://hamilton.apache.org/concepts/parallel-task/) see [this +For [this parallel task approach](https://hamilton.apache.org/concepts/parallel-task/) see [this example](https://github.com/apache/hamilton/tree/main/examples/LLM_Workflows/scraping_and_chunking) instead. diff --git a/examples/spark/pyspark/README.md b/examples/spark/pyspark/README.md index a9bb3cfc3..7d4057dec 100644 --- a/examples/spark/pyspark/README.md +++ b/examples/spark/pyspark/README.md @@ -196,7 +196,7 @@ import map_transforms # file defined above @with_columns( map_transforms, # Load all the functions we defined above - pass_dataframe_as="input_dataframe", #the upstream dataframe, referred to by downstream nodes, will have this parametter name + pass_dataframe_as="input_dataframe", #the upstream dataframe, referred to by downstream nodes, will have this parameter name ) def final_result(all_initial_data: ps.DataFrame) -> ps.DataFrame: """Gives the final result. This decorator will apply the transformations in the order. diff --git a/hamilton/plugins/README.md b/hamilton/plugins/README.md index 6dfa1821e..56425cb3a 100644 --- a/hamilton/plugins/README.md +++ b/hamilton/plugins/README.md @@ -20,7 +20,7 @@ under the License. # Plugins Apache Hamilton enables plugins -- the requirement is that the core library according to the plugin is installed, and the plugin will be registered automatically. -It is up to the user to install the plugin via the target, E.G. `hamilton[pyspark]`, which will install the correct depdendencies. +It is up to the user to install the plugin via the target, E.G. `hamilton[pyspark]`, which will install the correct dependencies. ## Structure diff --git a/ui/README.md b/ui/README.md index 4d54b76ca..8ab580fe1 100644 --- a/ui/README.md +++ b/ui/README.md @@ -125,7 +125,7 @@ This: 3. Publishes to the [apache-hamilton-ui](https://pypi.org/project/apache-hamilton-ui/) package on pypi Then you'll run it with `hamilton ui` after installing `apache-hamilton[ui]`. Note to -talk to it you'll need the hamilton_sdk pacakge which can be installed with `pip install apache-hamilton[sdk]`. +talk to it you'll need the hamilton_sdk package which can be installed with `pip install apache-hamilton[sdk]`. ## Building docker diff --git a/writeups/decorators.md b/writeups/decorators.md index 33619bbd5..085ec0820 100644 --- a/writeups/decorators.md +++ b/writeups/decorators.md @@ -87,7 +87,7 @@ tuple(Output Name, Documentation string) -> value. Note that `@parametrized` is deprecated, and we intend for you to use `@parameterize_vales`. We're consolidating to make the parameterization decorators more consistent! You have plenty of time to migrate, -we wont make this a hard change until we have a Apache Hamilton 2.0.0 to release. +we won't make this a hard change until we have a Apache Hamilton 2.0.0 to release. ## @parameterize_sources (replacing @parameterized_inputs) @@ -490,7 +490,7 @@ The inputs to the `subdag` decorator takes in a variety of inputs that determine Note that, if you wanted to do this functionality without this decorator, you'd have two options: -1. Rewrite every function for each scenario -- this is repetetive and doesn't scale +1. Rewrite every function for each scenario -- this is repetitive and doesn't scale 2. Utilize the `driver` within the functions -- E.G. ```python