This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Poetry: use locked environment in Docker images #12385
Poetry: use locked environment in Docker images #12385
Changes from 1 commit
cdad120
0a28d77
e741767
92c9a60
2afee3b
a1d7ba9
87ee7c2
5bc8eac
98e8b39
efeb99d
c791ed1
43b9b3e
432adf7
1a81c24
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@richvdh asked:
My understanding was that these just apply to the
builder
stage because we haven't yet begun to define the final stage.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.
right. I've not investigated in practice how this works for initial stages of Dockerfiles, but what I do know is that if you set an ENV in the final stage, you'll also get that env var in the final container. See https://docs.docker.com/engine/reference/builder/#env:
and:
My instinct here, irrespective of whether it does the right thing in practice, is to avoid the ambiguity by avoiding
ENV
.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 think I was allowing myself to be a little lazy since I was invoking poetry twice.
Now that we're able to export requirements.txt (92c9a60) this isn't needed.
For context: originally
poetry export
produced a requirements.txt file which omitted hashes for certain dependencies. That's a poetry bug. We were able to workaround this by adding a missing metadata dependency to Synapse (#12384) and tightening a signedjson dependency (matrix-org/python-signedjson#9). We only found the workaround last week, and I hadn't gone back to make use of requirements.txt here (if it ain't broke...).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.
@richvdh wondered:
It might be fine to copy the venv to
/usr/local
, but I wasn't certain; this change is me erring towards caution. See this comment thread.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 hadn't considered that people were building on top of our docker images. A quick search fins a few.
I couldn't find an equivalent to
pip install --prefix
in poetry last time I looked. But this comment python-poetry/poetry#234 (comment) might be useful.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.
If we could dump everything back in
/usr/local/
then we wouldn't need matrix-org/complement#337.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.
and I'll bet there are a whole bunch more that aren't on (public) github.
Copying a virtualenv wholesale into /usr/local doesn't sound like a thing that will work to me. If nothing else there will be a bunch of hardcoded paths which would need updating.
Ultimately, I think our best approach here is just going to be to warn people loudly that this is a change we are making. Which sounds to me like we should also get our story straight about how people are meant to install extensions (#9944) to avoid breaking things twice for people.
To decouple this... could we do the same thing as the debian build, and hack around with
poetry export
andpip install -r
?