PACK_DIR environment variable being ignored

[foxyseta]

This command seems to ignore the provided PACK_DIR value and install in .pack/bin anyway:

$ PACK_DIR=/home/foxy/desktop/ pack -p nightly-240617 install-app idris2-lsp

Or perhaps PACK_DIR is not meant to provide local installs in different directories, but only one global install directory at a time?

[stefan-hoeck]

I'll have a look at this.

[stefan-hoeck]

So, I tested this on my end: The program is installed at the correct location on my end but the lsp app requires also pack to be installed in the same $PACK_DIR, because it needs pack to resolve all library paths for the LSP.

So, currently PACK_DIR is used as a global install and not for different local installs. I'd be interested in your use case to find out how or if it is possible to make this more flexible.

[foxyseta]

At mason-org/mason-registry#5266, I am making idris2-lsp available to neovim users via one of its most popular package managers. Portability is one of mason's key features: All installed packages are isolated in a single local directory, so your system does not get dirtied.

One thing that * could * be possible w/o touching pack's codebase would be having a second pack install within the mason subdirectory where idris2-lsp is to be installed, but this does not really scale well to multiple mason packages making use of pack. As for now, idris2-lsp is the first pack app people are trying to merge.

[stefan-hoeck]

At mason-org/mason-registry#5266, I am making idris2-lsp available to neovim users via one of its most popular package managers. Portability is one of mason's key features: All installed packages are isolated in a single local directory, so your system does not get dirtied.

One thing that * could * be possible w/o touching pack's codebase would be having a second pack install within the mason subdirectory where idris2-lsp is to be installed, but this does not really scale well to multiple mason packages making use of pack. As for now, idris2-lsp is the first pack app people are trying to merge.

Would it be okay for your usecase to assume that pack must be installed an the pack executable on the $PATH? In that case, you could replace the calls to pack (via absolute paths) in the generated idris2-lsp shell script with just pack:

#!/bin/sh

if ! APPLICATION="$(pack app-path idris2-lsp)" || [ ! -r "$APPLICATION" ]; then {
  echo '[ fatal ] Package `idris2-lsp` is not built or not installed in the current'
  echo '          environment. Maybe, it was installed with an older compiler version'
  echo '          or using a local `pack.toml` which is not available in the current'
  echo '          directory. Try to reinstall it with `pack install-app idris2-lsp`.'

  } >&2; exit 2
fi
export IDRIS2_PACKAGE_PATH="$(pack package-path)"
export IDRIS2_LIBS="$(pack libs-path)"
export IDRIS2_DATA="$(pack data-path)"


$APPLICATION "$@"

[foxyseta]

Yes, I am sure that would be a reasonable assumption. However, idris2-lsp is not installed in the expected location to begin with, in my case. The command I am running is:

PACK_DIR=/home/foxy/desktop/ pack -p nightly-240617 install-app idris2-lsp