Deno: Possibility of `$DENO_DIR` working when read-only?

[TooTallNate]

👋

So I'm trying to deploy a deno script as an AWS Lambda function. The lambda .zip file contains a deno_dir that has been pre-populated with the cached files via deno cache. However, when AWS extracts this zip, the extracted files are read-only (and owned by the root user, which is different than the lambda user). As of deno v1.0.1, this causes a permissions error.

Is there a way to make this scenario work? Or am I better off using deno bundle (seems that source maps are not supported for bundle, which is unfortunate)?

[ry]

Hi Nate!

As of deno v1.0.1, this causes a permissions error.

Can you be more specific? Is it because only root can read those files or is Deno trying to be extra clever? I don't think Deno should try to examine the owner and try to enforce stricter permissions than the fs.

[TooTallNate]

The error is:

error: Could not create remote modules cache location: "/var/task/deno_dir/deps"
Check the permission of the directory.

The error message was added in https://github.com/denoland/deno/pull/5120, and apparently to address your comment here: https://github.com/denoland/deno/issues/2731#issuecomment-518428043.

/var/task/deno_dir/deps _does_ exist, and is owned by root, but the current user does have read permission. It seems that deno is trying to mkdir even though the dir already exists.

[TooTallNate]

Ok actually I lied, the gen dir _does exist_, however the deps dir _does not exist_. This is because in my simple case there were no import calls to external sources so it was an empty directory, and I'm guessing the zip file doesn't contain the empty directory.

So perhaps this issue is more about deferring the mkdir deps until it's actually needed? If I add an external import statement so that the deps dir is not empty, I get the results that I am expecting. So this issue is only relevant for simple scripts that do not import anything external.

[bartlomieju]

Ok actually I lied, the gen dir _does exist_, however the deps dir _does not exist_. This is because in my simple case there were no import calls to external sources so it was an empty directory, and I'm guessing the zip file doesn't contain the empty directory.

So perhaps this issue is more about deferring the mkdir deps until it's actually needed? If I add an external import statement so that the deps dir is not empty, I get the results that I am expecting. So this issue is only relevant for simple scripts that do not import anything external.

Hi @TooTallNate; I'll look into this issue. Just to confirm: you do not have any imports (neither local nor remote)? $DENO_DIR/deps is only used to store remote dependencies; local dependencies are not stored in $DENO_DIR (instead they are always read from their original location) - it means that you'll have to collect them manually before zipping.

[TooTallNate]

Hey @bartlomieju, thanks for chiming in 😃

Just to confirm: you do not have any imports (neither local nor remote)?

For this issue to surface, yes that's correct. Just a super basic hello world, such that the deps dir will be empty (as a result of deno cache). When moving this deno cache to the zip file and extracting into the Lambda environment, the empty deps dir gets lost along the way, and then deno run fails because it no longer has write access to this cache dir.

That said, it's an obscure scenario and unlikely for someone to encounter. But I think to patch up the rough edge, attempting to make the missing deps dir could only happen once an external source is being imported to avoid hitting the permissions error.

[bartlomieju]

@TooTallNate fix landed; it will be released in v1.0.3 in the next days.

[TooTallNate]

Awesome, thanks @bartlomieju!