improved get-poetry.py and added POETRY_HOME support to poetry command

[mohan43u]

• fixed prompting even after no-modify-path explicitly given in commandline
• use POETRY_HOME if available instead of XDG_*_HOME variables in nix systems

Pull Request Check List

Resolves: #3542
Resolves: #2445

• Added tests for changed code.
• Updated documentation for changed code.

[mohan43u]

Can someone review this code?

The changes I made helps keep everything related to 'poetry' inside one place under POETRY_HOME

[TBBle]

I don't see how this resolves #2445, unless the intention is to not support the cache-dir config option, or at least document that it only applies to the virtual-env default path and the 'artifacts' directory, but not other forms of caching done by Poetry.

[mohan43u]

I don't see how this resolves #2445,

given reply

unless the intention is to not support the cache-dir config option, or at least document that it only applies to the virtual-env default path and the 'artifacts' directory, but not other forms of caching done by Poetry.

I'm not able to understand but not other forms of caching done by Poetry part. could you please elaborate?

[TBBle]

Right now, the cache-dir config is used for 'virtualenv' (by default) and 'artifacts' (hard-coded), but not 'repositories' which ignores the setting and uses locations.CACHE_DIR. That's the problem seen in #2445, that sometimes it ignores the cache-dir config.

This PR doesn't change that behaviour, it instead adds POETRY_HOME as a preference over XDG_CACHE_HOME, which I separately think is the wrong approach, but certainly doesn't fix that the cache-dir config option should override this, and does not.

[mohan43u]

This PR doesn't change that behaviour, it instead adds POETRY_HOME as a preference over XDG_CACHE_HOME, which I separately think is the wrong approach, but certainly doesn't fix that the cache-dir config option should override this, and does not.

This PR doesn't address #2445 directly, but it fixes the underlying problem which lead to #2445 issue. As I already mentioned, XDG_*_HOME dirs are suppose to be fallback dirs when user not explicitly specify the location to store files. But poetry is using these dirs as they are the one user has to use and expects user to change XDG_*_HOME variables rather than providing a way to explicitly specify where to store the files.

[TBBle]

That's not the underlying problem in #2445. The underlying problem there is the surface problem:

poetry config cache-dir /tmp/poetrycache does not prevent Poetry trying to write to to $XDG_CACHE_HOME.

With this PR, the the same problem exists, except you add "or $POETRY_HOME/.cache" to the end of the problem description. It doesn't change the problem.

POETRY_HOME is not a way to "explicitly specify the location to store (cache) files". It's a way to explicitly specify the location to install Poetry's binaries when using get-poetry.py, which has no relationship with #2445.

[mohan43u]

There is no solution in current poetry to address the problem this PR is addressing which is providing user a way to explicitly specify the location to use rather than asking user to change XDG_*_HOME dirs.

[TBBle]

If by "location to use", you only mean "Poetry's cache files", then there is a documented solution, it just doesn't work: #2445.

If by "location to use" you include everything that Poetry touches (i.e. you want a "standalone" or "portable" install) then no, there isn't such a thing, but supporting that through POETRY_HOME doesn't fix #2445, which is a problem with redirecting Poetry's caches specifically, not producing a "standalone" install.

[neersighted]

Closing this for a couple reasons: get-poetry.py is deprecated, and $POETRY_HOME has always been meant to control where poetry's isolated environment is created, but it was not intended to silo all of the files poetry generates.

I do think it's worth addressing the inconsistent cache dir in poetry -- but this PR is only tangentially related and not the way to go about solving that problem.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.