Cleanup installation

[dvzrv]

Currently installation of etherpad-lite seems messy and it would be great to clean up the process. As noted in #3293, during install (whether manually or by means of installDeps.sh) the directory node_modules with the symlink ep_etherpad-lite -> ../src is created. However, I'd like to be able to package etherpad-lite with its source directory at /usr/share/etherpad-lite (symlink in packages should be considered a last resort). How do I achieve that? Doing the installation manually (not using the scripts in bin), I soon realized, that some of the linkage within etherpad-lite requires the (otherwise empty) node_modules directory to be around and I was not able to make it start by other means (so far).

[lpagliari]

Hey, @dvzrv , I'm still trying to understand everything you've written on this issue and on #3293 . Are both issues asking questions to handle the same problem? #3293 seems to be a more complete version f this one...

[dvzrv]

hey @lpagliari, both issues are packaging issues (in some ways), as packagers (should) care about where things are going in the local filesystem and what they are supposed to be able to do there.

However, #3293 is about problems with file and folder permissions, when trying to install etherpad-lite as a package. They result from the assumption, that the application is able to write to its installation folder. This is contrary to what is supposed to happen in a package.

This here issue is about - what seems to me - a historically grown way of installing etherpad-lite and its components to a folder (i.e. src), which then still requires an out of tree folder with a symlink in it for it to work (i.e. node_modules). For further evaluation check out run.sh and (by proxy) installDeps.sh. I know this is the current recommended way of installing and starting etherpad-lite for users, but I think it could use some improvements.

[teknopaul]

Agree generally with dvzrv.

Some feed back installing epad on the raspberypi...

Any issues in the current install and it deletes everything its done so far...

... npm install --no-save --loglevel warn ) || { rm -rf src/node_modules exit 1 }

this complicates debugging issues with the install.

Running on an rpi the install takes a long time, restarting the whole process after any temporary failure and re-downloading 100+ Mb of data.

Install is executed every time the server is started in Linux. One I/O error in NPM causes node_modules to be deleted and you have to reinstall from scratch. Perhaps always updating the software should be an option on boot for people wanting bleeding edge over stability?

Given that npm don't support the latest version of npm available for the rpi right now, npm is not really usable on the raspberypi. I suspect a previous working install would stop working if npm went out of date, even tho no local code to the etherpad instance needs to change. AFAICS bin/installDeps.sh would actually break a working install.

Minimum npm version is greater than latest provided by Ubuntu LTS at time of writing. By removing the npm version check I was able to run installDeps.sh without issues in Ubuntu LTS, not sure why its felt this version is needed?

npm install --no-save --loglevel warn

completed with out errors in Ubuntu LTS's npm 3.5.2

By rsyncing the resulting folder to the rpi, commenting out bin/installDeps.sh in bin/run.sh it runs OK on the pi, since there is no native code in the deps.

So it seems npm is not really a runtime dependency? If it could build to a ./target directory life would be easier for packagers.

Since there in a Makefile running ./configure; make; make install would be an idiomatic build procedure for Linux types.

Pleased it works on the rpi, VSZ 174,676Kb RSS 61,344Kb :)

[muxator]

This continues to be a pain point for me.

Reworking the folder structure will require restructuring some code deep inside Etherpad core, particularly wrt how plugins are installed / uninstalled (yes: it's different because of npm's API :smile: ).

The conflagration of the "dev" experience and "production" experience exacerbates this, together with the lack of a real build step. We have also to admit that this software was born when the Nodejs ecosystem was in its infancy.

I do not know if everything (https://github.com/ether/etherpad-lite/labels/packaging) can be fixed in a short time.

I'd try to start to set a somewhat simpler goal, that maybe can help towards the final goal of a sane disk layout, and thus try to work on #3936 (but allowing me the possibility of sliding it forward).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.