Permissions issues.

[jordwalke]

People tend to do sudo to globally install a module. But reason-cli quickly cds into actualInstall where we do the real install / build locally.

That second install is done as sudo, yet it's a local project from the perspective of yarn which is used under the hood. I believe there's some yarn permissions issues if the first time you ever create the ~/.cache/yarn directory is invoked with sudo. It will set perms to be root or something. The ~/.cache is to be used for local projects. If you install a local yarn project using sudo the same issue would likely happen.
I'm not sure what the solution is.

[ghost]

I also encountered this issue. I resolved it by a very temporary solution chmod 777 ~/.cache. But then other issues come up later to me.

[kennetpostigo]

Not sure if related but, my install "succeeds" but the output says 0/34. So not sure if anything was actually installed.

[jordwalke]

I tried on another clean OS install (ElementaryOS VM) and it worked perfectly. I think Ubuntu had issues. It would be great if someone can pinpoint what the problem is.

[jordwalke]

I mentioned that one solution is to just vendor all the dependencies : that's quite easy and takes yarn completely out of the equation. It works on any node version as well. Just a thought.

[ghost]

I'm also running into the permission problems trying to install this on Ubuntu 17.04 server. I have to use sudo or else it fails trying to install things under /user/lib/node_modules. But with sudo it still fails with Error: EACCES: permission denied, mkdir '~/.cache/yarn'.

I've noticed it gives the latter error even if ~/.cache/yarn already exists, and even with chmod 777. I think in that case it may be failing because it's trying to call mkdir and the directory already exists, which I think will usually give an error unless you override it. If that's the case, it should check for existence first instead.

[jordwalke]

@andreypopp

This is an example of one of the permissions issues that yarn is causing. Do you think upgrading to the latest yarn would fix things?

[andreypopp]

I'll try to repro now as I merged the latest yarn source tree into esy.

…

On Sat, 20 May 2017 at 09:22 Jordan W ***@***.***> wrote: @andreypopp <https://github.com/andreypopp> This is an example of one of the permissions issues that yarn is causing. Do you think upgrading to the latest yarn would fix things? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB3giQSuqtu8gyzyI4SRkA1fN47JLlRks5r7oa4gaJpZM4NFUIJ> .

[andreypopp]

Looks like the reason it doesn't install is npm/npm#3849 which tl;dr is "npm runs lifecycle scripts with nobody uid".

node behaves strangely when trying to get the user's homedir in case nobody:

> require('os').homedir()
/home/<actualuserhomedir>

Which nobody can't write to obviously.

That + the fact that yarn for some reason attempts to create ~/.cache/yarn even it is configured with another --cache-folder makes sudo npm install -g reason-cli fail.

Even in case we fix yarn not to mkdir ~/.cache/yarn we can't write into ~/.esy. That means we can only tweak $HOME in postinstall script so that writes to ~ succeed.

The downside is that such global installations won't warm up Esy cache.

[andreypopp]

Hah, setting export HOME="$PWD" makes us hit shebang line limitations which is 127 bytes on Linux. While

#!/usr/local/lib/node_modules/reason-cli/.esy/store-3.x.x/_install/ocaml-4.02.3-d8a857f3f011c1bc6b13e32bf45caaa8171a4f7a/bin/ocamlrun

is 131 bytes long.

[andreypopp]

Just for the record: sudo yarn global add reason-cli works on Linux.

[jordwalke]

The shebang limitations are a known issue with installing any interpreter not in the global directories like /usr/bin. I've hit it before when setting my artifact cache to some deep location while testing. There's some things we could/should do:

• Shorten store-3.x.x to 3.x.x.
• Only take the first eight characters of every hash. ocaml-4.02.3-d8a857f3 etc.

That should eliminate many cases of shebang limits and generally make all the log outputs look nicer.

[jordwalke]

Does this mean that any postinstall script that wants to write to a user's home directory will fail - but only on ubuntu?

[andreypopp]

• Shorten store-3.x.x to 3.x.x.
• Only take the first eight characters of every hash. ocaml-4.02.3-d8a857f3 etc.

Yeah, that's a good idea.

Does this mean that any postinstall script that wants to write to a user's home directory will fail - but only on ubuntu?

I suspect any Linux.

[andreypopp]

I think at this point we could consider an alternative for global installs with Esy.

% npm install -g esy
% esy global install reason-cli

That's two commands rather than a single one but still easy to start with. Though agree it lacks an elegance of "using the known tooling" — npm.

I think that could solve permission issues without sacrificing warming up Esy cache.

[jordwalke]

Is there really no other way around it? What about ejecting to a shell script that downloads packages into the proper/expected node_modules structure. If that is a desired feature anyways, does it solve any problems here?

[c9rl]

Hello! I wanted to tinker around with Reason and tried installing it using npm, however ran into the same issues mentioned here and here - essentially this error Error: EACCES: permission denied, mkdir '~/.cache/yarn',. I tried uninstalling / reinstalling, but to no avail, ending up in the same situation.

For the time being I'm going to try installing from OPAM.

[jordwalke]

Okay, opam is (until we get reliable binary releases) the officially supported installation method and hopefully we'll have good news soon about reason-cli permissions issues.

[mini-eggs]

For anyone coming across this:

On a new Debian Stretch install. npm install and sudo npm install both failed (with permission issues but in different locations).

yarn global add whatever worked great, though.

[jordwalke]

@mini-eggs Would be great to know the npm version and how node/npm were installed (nvm?)

[mini-eggs]

@jordwalke

No problem!

No NVM:

evan@debian:~$ npm --version
5.6.0
evan@debian:~$ node --version
v9.4.0