Provide more information regarding --no-cache flag

[mwgamble]

• I have searched the issues of this repo and believe that this is not a duplicate.

Issue

It isn't clear what the --no-cache flag does. The documentations says it disables "source caches", but it isn't clear what those are.

I was expecting something along the same lines as the --no-cache-dir flag for pip install, but it seems it doesn't behave that way. Is there something else we should be doing to empty caches for container image builds?

[neersighted]

Poetry caches metadata and distfiles from package sources (aka repositories aka indexes). If you are looking to nuke the cache, I would generally suggest a multi-stage build as a cleaner solution as virtual environments can be copied across stages without issue.

However, if you wish to avoid a multi-stage build, poetry -n cache clear --all . ought to suffice (though there is a bug in 1.2.0 about to get fixed in 1.2.1 related to the prompt not working) -- rm -rf ~/.cache/pypoetry/artifacts and rm -rf ~/.cache/pypoetry/cache ought to clear the relevant caches for you as well.

The --no-cache flag disables the use of caches globally, forcing Poetry to behave as if it had a cold cache all the time.

[mwgamble]

That would be great information to include in the documentation. Coming from pip and its --no-cache-dir flag, I expected it to control whether or not the actual package downloads from PyPI get cached or not.

[Trolldemorted]

Poetry caches metadata and distfiles from package sources (aka repositories aka indexes). If you are looking to nuke the cache, I >would generally suggest a multi-stage build as a cleaner solution as virtual environments can be copied across stages without >issue.

Is there documentation about that? Iirc venvs contain absolute paths, and should not be moved unless you really know what you are doing.

[neersighted]

When I refer to 'copying without issue,' I'm really referring to using the same paths on the same base image, but in a different build stage without common layers. This is definitely a reduced subset of 'safe' operations, but I do think it represents a workflow that is common/most likely to make sense for most container builders.

[matejsp]

We just got bitten by cached artifacts. poetry lock resolved hashes from whls that are stored in artifacts folder. Because of that we got different hashes that from our nexus that we use as repostiory.

Even after running poetry cache clear --all . didn't help.

After manually deleting rm -rf ~/Library/Caches/pypoetry/artifacts (btw it accumulated couple of GB of data).

Basically cache clear should delete also cached artifacts.