infra: Resolve the endless dependency resolution during the build of dev.Dockerfile by copying poetry.lock
#19465
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
dosubot
bot
added
size:XS
gkorland
pushed a commit
to FalkorDB/langchain
that referenced
this pull request
Mar 30, 2024
…`dev.Dockerfile` by copying `poetry.lock` (langchain-ai#19465) ## Description This PR proposes a modification to the `libs/langchain/dev.Dockerfile` configuration to copy the `libs/langchain/poetry.lock` into the working directory. The change aims to address the issue where the Poetry install command, the last command in the `dev.Dockerfile`, takes excessively long hours, and to ensure the reproducibility of the poetry environment in the devcontainer. ## Problem The `dev.Dockerfile`, prepared for development environments such as `.devcontainer`, encounters an unending dependency resolution when attempting the Poetry installation. ### Steps to Reproduce Execute the following build command: ```bash docker build -f libs/langchain/dev.Dockerfile . ``` ### Current Behavior The Docker build process gets stuck at the following step, which, in my experience, did not conclude even after an entire night: ``` => [langchain-dev-dependencies 4/6] COPY libs/community/ ../community/ 0.9s => [langchain-dev-dependencies 5/6] COPY libs/text-splitters/ ../text-splitters/ 0.0s => [langchain-dev-dependencies 6/6] RUN poetry install --no-interaction --no-ansi --with dev,test,docs 12.3s => => # Updating dependencies => => # Resolving dependencies... ``` ### Expected Behavior The Docker build completes in a realistic timeframe. By applying this PR, the build finishes within a few minutes. ### Analysis The complexity of LangChain's dependencies has reached a point where Poetry is required to resolve dependencies akin to threading a needle. Consequently, poetry install fails to complete in a practical timeframe. ## Solution The solution for dependency resolution is already recorded in `libs/langchain/poetry.lock`, so we can use it. When copying `project.toml` and `poetry.toml`, the `poetry.lock` located in the same directory should also be copied. ```diff # Copy only the dependency files for installation -COPY libs/langchain/pyproject.toml libs/langchain/poetry.toml ./ +COPY libs/langchain/pyproject.toml libs/langchain/poetry.toml libs/langchain/poetry.lock ./ ``` ## Note I am not intimately familiar with the historical context of the `dev.Dockerfile` and thus do not know why `poetry.lock` has not been copied until now. It might have been an oversight, or perhaps dependency resolution used to complete quickly even without the `poetry.lock` file in the past. However, if there are deliberate reasons why copying `poetry.lock` is not advisable, please just close this PR.
hinthornw
pushed a commit
that referenced
this pull request
Apr 26, 2024
…`dev.Dockerfile` by copying `poetry.lock` (#19465) ## Description This PR proposes a modification to the `libs/langchain/dev.Dockerfile` configuration to copy the `libs/langchain/poetry.lock` into the working directory. The change aims to address the issue where the Poetry install command, the last command in the `dev.Dockerfile`, takes excessively long hours, and to ensure the reproducibility of the poetry environment in the devcontainer. ## Problem The `dev.Dockerfile`, prepared for development environments such as `.devcontainer`, encounters an unending dependency resolution when attempting the Poetry installation. ### Steps to Reproduce Execute the following build command: ```bash docker build -f libs/langchain/dev.Dockerfile . ``` ### Current Behavior The Docker build process gets stuck at the following step, which, in my experience, did not conclude even after an entire night: ``` => [langchain-dev-dependencies 4/6] COPY libs/community/ ../community/ 0.9s => [langchain-dev-dependencies 5/6] COPY libs/text-splitters/ ../text-splitters/ 0.0s => [langchain-dev-dependencies 6/6] RUN poetry install --no-interaction --no-ansi --with dev,test,docs 12.3s => => # Updating dependencies => => # Resolving dependencies... ``` ### Expected Behavior The Docker build completes in a realistic timeframe. By applying this PR, the build finishes within a few minutes. ### Analysis The complexity of LangChain's dependencies has reached a point where Poetry is required to resolve dependencies akin to threading a needle. Consequently, poetry install fails to complete in a practical timeframe. ## Solution The solution for dependency resolution is already recorded in `libs/langchain/poetry.lock`, so we can use it. When copying `project.toml` and `poetry.toml`, the `poetry.lock` located in the same directory should also be copied. ```diff # Copy only the dependency files for installation -COPY libs/langchain/pyproject.toml libs/langchain/poetry.toml ./ +COPY libs/langchain/pyproject.toml libs/langchain/poetry.toml libs/langchain/poetry.lock ./ ``` ## Note I am not intimately familiar with the historical context of the `dev.Dockerfile` and thus do not know why `poetry.lock` has not been copied until now. It might have been an oversight, or perhaps dependency resolution used to complete quickly even without the `poetry.lock` file in the past. However, if there are deliberate reasons why copying `poetry.lock` is not advisable, please just close this PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR proposes a modification to the
libs/langchain/dev.Dockerfileconfiguration to copy thelibs/langchain/poetry.lockinto the working directory. The change aims to address the issue where the Poetry install command, the last command in thedev.Dockerfile, takes excessively long hours, and to ensure the reproducibility of the poetry environment in the devcontainer.Problem
The
dev.Dockerfile, prepared for development environments such as.devcontainer, encounters an unending dependency resolution when attempting the Poetry installation.Steps to Reproduce
Execute the following build command:
docker build -f libs/langchain/dev.Dockerfile .Current Behavior
The Docker build process gets stuck at the following step, which, in my experience, did not conclude even after an entire night:
Expected Behavior
The Docker build completes in a realistic timeframe. By applying this PR, the build finishes within a few minutes.
Analysis
The complexity of LangChain's dependencies has reached a point where Poetry is required to resolve dependencies akin to threading a needle. Consequently, poetry install fails to complete in a practical timeframe.
Solution
The solution for dependency resolution is already recorded in
libs/langchain/poetry.lock, so we can use it. When copyingproject.tomlandpoetry.toml, thepoetry.locklocated in the same directory should also be copied.Note
I am not intimately familiar with the historical context of the
dev.Dockerfileand thus do not know whypoetry.lockhas not been copied until now. It might have been an oversight, or perhaps dependency resolution used to complete quickly even without thepoetry.lockfile in the past. However, if there are deliberate reasons why copyingpoetry.lockis not advisable, please just close this PR.