Open codetent opened 3 years ago
hi @codetent
Sorry I missed this issue back in December. This sort of use case is typically covered by setting SHIV_ROOT
in a wrapper script. For example, one we use internally at LinkedIn is:
#!/bin/bash
[ -z "$BASEDIR" ] && export BASEDIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd )
/usr/bin/env SHIV_ROOT="$BASEDIR/libexec" SHIV_ENTRY_POINT="some_package:main" $BASEDIR/bin/server.pyz "$@"
Note the combination of the $BASEDIR
variable in the SHIV_ROOT
that we set.
I'm interested to understand what you mean about the overhead of creating environment variables, so I can understand the context of your ask better :)
Thanks! And sorry again for the delay in replying!
hi @lorencarvalho Thanks for your reply. No problem :-)
In my case, the shiv archive is appended to the pylauncher executable for Windows. This makes it possible to have a single .exe executable which launches the appended script or file. Unfortunately, I can't use an additonal wrapper script because the launcher only works for a single python script or pyz archive.
My first idea was manipulating the environment variable using the preamble feature but as this is called after writing files to shiv root this is not possible. I am afraid that currently the only way to get it working is creating an executable which calls the pyz file with the required environment variable, but then there are two files instead of just one .exe file :-(. That's what I meant by overhead.
Hi guys! @lorencarvalho, does--root
uses an expandvars
?
I would personally like end user's shiv root being directed from the different env variable. That would help me and if I am not mistaken, also could help in this issue, if shiv could inject special variables, like SHIV_APP_DIR
.
It seems that environment variables are resolved if just a single var like "$ENV" is set but they are not really expanded if there is a path suffix. I agree that expanding env vars is probably a good idea but unfortunately it does not help me in this case.
I would appreciate if --root
works like this:
I currently have the problem that I want to move my cache directory relative to the executable path (sys.argv[0]).
This is needed because I want to have a shiv package distributed with an installer and all the package data at the installation directory. If the cache is global (e.g. ~/.shiv) I cannot remove it easily when deinstalling the package. Currently, I can only set the path to a directory relative to the current working directory or an environment variable. This is not feasible for me because the cwd can change and creating an environment variable would be a big overhead if installing multiple versions.
It would be great if I could specify something like "--root $pkg/cache" (introduce a special variable) or change the behavior to resolve "--root ./cache" relative to the sys.argv[0] directory. The first solution would also enable that you can use a subdirectory of a path set by a normal environment variable.