Cannot create virtual environment by default on Ubuntu 22.04 amd64

[JMadgwick]

Somewhat similar to #356 but on amd64 and with a different error in one case. The workaround given there also works for this problem.

Steps to reproduce (I tested with a freshly installed VM):

1. Download GraalPy 23.1.2 (I used graalpy-23.1.2-linux-amd64)
2. Add bin to $PATH
3. Run: graalpy -m venv venv-dir

When using graalpy-23.1.2-linux-amd64.tar.gz, I got the error:

Error: [Errno 13] Permission denied: '/home/ubuntu/venv-dir/bin/ubuntu'

But when using graalpy-jvm-23.1.2-linux-amd64.tar.gz, I got a different error:

Error: [Errno 36] File name too long: '/home/ubuntu/venv-dir/bin/modules -Djdk.module.main=org.graalvm.py.launcher -Dgraalvm.locatorDisabled=true -classpath  com.oracle.graal.python.shell.GraalPythonMain'

This is the command which works around this issue to create a virtual environment:

./graalpy-23.1.2-linux-amd64/bin/graalpy --python.Executable=/home/ubuntu/graalpy-23.1.2-linux-amd64/bin/graalpy -m venv myvenv

Ideally this should be fixed soon or the documentation updated; as following the instruction there won't work, at least not with Ubuntu 22.04 amd64 which is very common.

[steve-s]

Hello @JMadgwick,

thanks for the report. I have tried reproducing this on Ubuntu 22.04 amd64 box, but without any luck. Could you please clarify this:

• for non-jvm graalpy (i.e., graalpy-23.1.2-linux-amd64.tar.gz):
  • The Error: [Errno 13] Permission denied issue with non-jvm graalpy distribution is expected, correct?
  • If you use different destination directory for the venv for which you have the permissions, does it work as expected?
    • In case you run /full/path/to/graalpy/bin/graalpy -m venv ...
    • In case you put /full/path/to/graalpy/bin on $PATH and execute just graalpy -m venv ...
• for jvm graalpy (i.e., graalpy-jvm-23.1.2-linux-amd64.tar.gz):
  • Do you get Error: [Errno 36] File name too long:
    • In case you run /full/path/to/graalpy/bin/graalpy -m venv ...
    • In case you put /full/path/to/graalpy/bin on $PATH and execute just graalpy -m venv ... (could you try prepending /full/path/to/graalpy/bin to rule out some issue with other things you may have on $PATH)

By any chance, are you running this on some container that you could share?

Otherwise, it would be helpful if you could share output of the problematic command run with VERBOSE_GRAALVM_LAUNCHERS=true, e.g., VERBOSE_GRAALVM_LAUNCHERS=true graalpy -m venv /path/to/venv.

I suspect that the issue could be the way we resolve full path to graalpy executable in case it is run from $PATH. We search $PATH and try to find directory that has graalpy (more precisely argv[0]) in it. Can you share what you have in $PATH or if there are some unusual things, like paths with spaces, etc.

[JMadgwick]

• The Error: [Errno 13] Permission denied issue with non-jvm graalpy distribution is expected, correct?
• If you use different destination directory for the venv for which you have the permissions, does it work as expected?

This error is not expected. The graalpy installation is in a directory within the user's home directory and the command to create a venv is also run from with the user's home directory. There are no permissions issues.

• In case you run /full/path/to/graalpy/bin/graalpy -m venv ...

This works correctly. Although it didn't seem to the first few times I tried, then it started working.

In case you put /full/path/to/graalpy/bin on $PATH and execute just graalpy -m venv ...

Same as before, does not work.

• for jvm graalpy (i.e., graalpy-jvm-23.1.2-linux-amd64.tar.gz):
  • Do you get Error: [Errno 36] File name too long:
    • In case you run /full/path/to/graalpy/bin/graalpy -m venv ...

This works correctly.

• In case you put /full/path/to/graalpy/bin on $PATH and execute just graalpy -m venv ... (could you try prepending /full/path/to/graalpy/bin to rule out some issue with other things you may have on $PATH)

Does not work when doing export PATH=$PATH:/home/user/.local/graalpy-23.1.2-linux-amd64/bin. Error: Error: [Errno 36] File name too long: '/home/user/subdir/venv/bin/modules -Djdk.module.main=org.graalvm.py.launcher -Dgraalvm.locatorDisabled=true -classpath com.oracle.graal.python.shell.GraalPythonMain'

However, when prepending the path (export PATH=/home/user/.local/graalpy-23.1.2-jvm-linux-amd64/bin:$PATH) it does work.

By any chance, are you running this on some container that you could share?

I've not tried this yet.

Otherwise, it would be helpful if you could share output of the problematic command run with VERBOSE_GRAALVM_LAUNCHERS=true, e.g., VERBOSE_GRAALVM_LAUNCHERS=true graalpy -m venv /path/to/venv.

As above, path resolution appears to be the issue. This is the full output with verbose when not working:

export PATH=$PATH:/home/user/.local/graalpy-23.1.2-linux-amd64/bin
VERBOSE_GRAALVM_LAUNCHERS=true graalpy -m venv newenv
org.graalvm.launcher.executablename set to '-Dorg.graalvm.launcher.executablename=graalpy'
Setting VM argument -Dorg.graalvm.launcher.executablename=graalpy
Loading library /home/user/.local/graalpy-23.1.2-linux-amd64/bin/../lib/libpythonvm.so
Error: [Errno 13] Permission denied: '/home/user/subdir/newenv/bin/subdir'

I suspect that the issue could be the way we resolve full path to graalpy executable in case it is run from $PATH. We search $PATH and try to find directory that has graalpy (more precisely argv[0]) in it. Can you share what you have in $PATH or if there are some unusual things, like paths with spaces, etc.

Yes, it seems there's something wrong with this logic. My $PATH contains nothing special: /home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/rocm/bin:/snap/bin

[steve-s]

Thank you, I could reproduce the issue. The fix is on its way.