WSL: Add how to handle strange permission error

[tobiasdiez]

On WSL you sometimes hit a strange "Permission denied" error while building other packages (always during copying of the dist-info file). There are some discussions online (like pypa/packaging-problems#258) and a few workarounds. The only thing that worked for me is no use a folder under the sage directory for building by setting SAGE_BUILD_DIR. So I've added this to the documentation in case someone else also encounters this error.

By the way, is it by design that the other sage packages like sage_conf ignore SAGE_BUILD_DIR? Same question for the docbuild.

CC: @mkoeppe

Component: documentation

Author: Tobias Diez

Branch/Commit: a74251f

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/32714

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9b5d30f

WSL: Add how to handle strange permission error

[sagetrac-git]

Commit: 9b5d30f

[mkoeppe]

comment:4

It would be more idiomatic to use just SAGE_BUILD_DIR="~/tmp/sage" make, not eval SAGE_BUILD_DIR="~/tmp/sage" make

[mkoeppe]

comment:5

Is your Sage source tree somewhere in /mnt/c?

[tobiasdiez]

comment:6

Replying to @mkoeppe:

It would be more idiomatic to use just SAGE_BUILD_DIR="~/tmp/sage" make, not eval SAGE_BUILD_DIR="~/tmp/sage" make

I think I tried this first and ended up with a ~ folder in the root sage project folder.

[tobiasdiez]

comment:7

Replying to @mkoeppe:

Is your Sage source tree somewhere in /mnt/c?

Yes, the source files are in the Windows file system (as I want to use git etc from Windows). I know it's not ideal and might switch to the linux file system in the future. But apart from this permission error everything is working.

[mkoeppe]

comment:8

Perhaps then better advice to give to the user would be to use configure --prefix=/SOME/LINUX/DIRECTORY? That would solve the problem too and is easier to explain.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

5988443	Merge branch 'develop' of git://github.com/sagemath/sage into public/docs/wsl_permission_error
e1605e3	Use prefix instead of build dir

[sagetrac-git]

Changed commit from 9b5d30f to e1605e3

[tobiasdiez]

comment:10

Replying to @mkoeppe:

Perhaps then better advice to give to the user would be to use configure --prefix=/SOME/LINUX/DIRECTORY? That would solve the problem too and is easier to explain.

Good suggestion! I tried it and confirmed it worked as well. Changed the docs accordingly now.

sage-conf etc are still not working, since they seem to respect neither prefix nor build dir. But that's something for another ticket.

[mkoeppe]

comment:11

--prefix is not some kind of temporary directory. It is the installation prefix. See README.md

[tobiasdiez]

comment:12

I know, but aren't these build artifacts some kind of semi-temporary files that can "easily" be recreated in case they got deleted? I'm not familiar with the linux conventions, what would be a good folder? /var/tmp?

[mkoeppe]

comment:13

Replying to @tobiasdiez:

I know, but aren't these build artifacts some kind of semi-temporary files that can "easily" be recreated in case they got deleted?

No. --prefix sets the SAGE_LOCAL directory. You can delete everything but this directory and have a working Sage.

Its subdirectory, SAGE_LOCAL/var/tmp/sage/build is used for temporary files during the build.

What I am saying is, we should give users on WSL the advice to create the installation hierarchy (SAGE_LOCAL) in a WSL directory, not a /mnt directory.
This should be general advice for from source installs in WSL; not troubleshooting advice ("how to fix a problem").

[tobiasdiez]

comment:14

Replying to @mkoeppe:

Replying to @tobiasdiez:

I know, but aren't these build artifacts some kind of semi-temporary files that can "easily" be recreated in case they got deleted?

No. --prefix sets the SAGE_LOCAL directory. You can delete everything but this directory and have a working Sage.

I understood this, but thought I edited the "developer" guide where you would treat this as only as a semi-temporary build output and not as a valid installation that you try to keep. Will change that later.

[mkoeppe]

comment:15

Everything is sort of temporary, of course. But in a Unix context, /tmp is a directory that one can expect to be emptied at a reboot; and /var/tmp is a directory that will be emptied periodically, at the discretion of a system administrator or scripts. Neither of these two fits a typical use case of what a developers does with --prefix.

[sagetrac-git]

Changed commit from e1605e3 to bbf4b89

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

bbf4b89

Recommend to put in linux file system

[tobiasdiez]

comment:18

I've now added a recommendation to put the source files in the linux file system so that the error doesn't occur in the first place. However, WSL has a few limitations and performance problems if you try to access files across the Windows <> Linux bridge; thus in some cases you might still prefer to put the files under the windows file system. In this case the workaround is still necessary.

Also I've changed the workaround back to use use SAGE_BUILD_DIR as setting the prefix slowed down the build process considerably and had other issues.

[mkoeppe]

comment:19

The rst markup doesn't look quite right, have you built the HTML doc?

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

6012ea3	Merge branch 'develop' of https://github.com/sagemath/sage into public/docs/wsl_permission_error
a74251f	Fix markup

[sagetrac-git]

Changed commit from bbf4b89 to a74251f

[tobiasdiez]

comment:21

Sorry, still living to much in a markdown world. Should be fine now.

[mkoeppe]

Reviewer: Matthias Koeppe

[tobiasdiez]

comment:23

Thanks

[vbraun]

Changed branch from public/docs/wsl_permission_error to a74251f

[kwankyu]

Could this happen with WSL 2?

If it was only an issue with WSL, I would delete this remark

https://doc-pr-38659--sagemath.netlify.app/html/en/installation/source#wsl-permission-denied-error-when-building-packaging-package

in #38659.