-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes to support poetry export plugin #146
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a question but LGTM!
Dockerfile
Outdated
@@ -33,7 +33,8 @@ ENV PYTHONPATH="${PYTHONPATH}:/app" | |||
# Install dependencies and start app | |||
WORKDIR /app | |||
COPY pyproject.toml poetry.lock ./ | |||
RUN poetry export -f requirements.txt --output requirements.txt | |||
RUN poetry self add poetry-plugin-export | |||
RUN poetry export --without-hashes --format=requirements.txt > requirements.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were hashes creating a problem in the output?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While working through this issue, I came across a GitHub issue (python-poetry/poetry-plugin-export#69) that discussed a potential problem with hashes in requirements.txt
. It explained that while hashes weren't causing issues yet, they could become problematic for VCS dependencies, as pip
can't verify hashes for them. To avoid any future installation errors, the solution proposed was to use the --without-hashes
flag, which excludes the hashes from the requirements.txt file
.
I'm open to switching back to hashes if we think there is an advantage keeping them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For security reasons, if we're not using VCS dependencies, it'd be preferable to keep them in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure Dan. Let's keep them then.
These changes resolve #145 due to which we were facing the local docker compose issue.