If you’re at least vaguely interested in this (even if it feels a bit intimidating, or you don’t want to commit to anything), could you reply here with a brief note about your level of interest, and anything in particular that’s acting as a barrier-to-entry?
I have the sense it may be worth investing a lot of effort into making the open source system here good, but wanted some sense of how many people might be willing to help.
I am at least vaguely interested. Possible barriers to entry in my case are (1) having other higher-priority calls on my time, (2) the machine I spend most time on being a Windows box rather than Linux or Mac (I have literally no idea whether that is actually an obstacle; I know it was for old-LW), (3) general disorganization and shortage of Round Tuits, and (4) unfamiliarity with some of the specific technologies used.
Of these, #1 and #3 probably aren’t going to go away, #2 may be a non-issue (perhaps someone can comment?), and #4 serves mostly to make #1 and #3 more severe (because it makes getting started feel like a bigger investment of time).
The most effective way (of those actually available to LW developers) to make me[1] more likely to contribute is probably to provide high-level documentation of the system—the sort of thing in the OP here, in fact—so that getting into it is as painless-in-expectation as possible.
[1] Not that making me in particular more likely to contribute should be anyone’s goal (unless maybe my own), but maybe there are others who feel the same way.
On #2, I just tried the Obvious Thing of running the commands listed in the OP on my Windows machine (ordinary Windows command prompt, not MinGW or WSL or anything of the sort). Here is what happened.
The npm install command failed. What I believe to be the first informative line of the error message said Error: Can’t find Python executable “python”, you can set the PYTHON env variable. Indeed I don’t have a PYTHON environment variable set. A bit of googling suggests that on systems where it is set it ought to point to the Python executable. So I said set PATH=C:\ProgramData\Anaconda3\python.exe which is where my Python interpreter lives, and I got the same error except that it said Can’t find Python executable “C:\ProgramData\Anaconda3\python.exe” which, since that file is definitely there, I took to mean that it failed to work in some way.
I tried doing the same from an “Anaconda prompt” (i.e., a command prompt with all environment variables set up suitably) and it failed in pretty much the same way except that it had ”.EXE” instead of ”.exe” at the end of the Python executable name it said it couldn’t find.
Perhaps we need Python 2 rather than Python 3. So I installed Python 2.7.15 (vanilla install from python.org rather than via Anaconda), set PYTHON=C:\Python27\python.exe, and tried again. This time it apparently worked, though there were a bunch of warnings.
Then npm start failed completely, because it tries to run a bash script. Oh well, never mind.
Next try: launch a WSL bash prompt, cd /mnt/c/Users/… and try again from the top. My Ubuntu-inside-Windows doesn’t have any version of Python installed by default, so sudo apt install python-minimal (which uses Python 2 rather than Python 3) before proceeding.
Now running npm install fails in a different and more immediate way: before it even tries to do anything, three error messages, two of which are … not found and the last of which is Syntax error: word unexpected (expecting “in”). I think what’s happening is that my pseudo-Linux shell is trying to run npm from my Windows installation of npm, and then getting confused by DOS-style line endings or something of the kind. (There is quite good evidence for this in the actual error messages.)
Next try: install nodejs and npm inside pseudo-Linux and try again. The result is the same, which doesn’t make any sense to me.
So, current suggestion: step 0 is “Be running Linux or macOS” for now. May also need “make sure you have Python 2 installed”?
I’ll continue trying to get it working later, but right now I’m at work and need to be doing other things :-).
Continuing attempts on WSL under Windows 10. I killed the bash prompt I had, and started a new one. This now seems to find the correct version of npm in preference to my Windows one, and npm install no longer fails instantly.
Unfortunately, it does still fail. After downloading a bunch of things, I get a bunch of errors associated with something called chromedriver. The first error message line says ERR! Linux-4.4.0-17134-Microsoft. Perhaps this means something has tried to figure out what sort of system it’s running on and doesn’t recognize what WSL reports? Possibly-informative later lines of the error message say ERR! code ELIFECYCLE and ERR! errno ENOENT. I can’t find anything in the node_modules directory relating to chromedriver; perhaps when something fails to install npm destroys the evidence? Scrolling back, I see that there’s an earlier sign of trouble: a line of the form > chromedriver@2.38.3 install [path to chromedriver module] (note: that path no longer exists in my filesystem) followed by a line of the form > node install.js followed by a blank line and then sh: 1: node: not found. After that comes a line beginning with “Vulcan” and then a big tree diagram of modules, then some dependency-related warnings, and then the errors I mentioned above.
[EDITED to add:] It turns out that on Ubuntu (which is the particular flavour of WSL I’m using) the nodejs package doesn’t provide a node executable because there’s another Ubuntu package that wants to call its executable node. So you need to install nodejs-legacy which I think just makes there be a symlink. And with that, npm install completes.
Now, of course, npm start fails. Meteor gets installed, we get a proxy started, but then three lots of Unexpected mongo exit code 100. Restarting. and some guesses at what Mongo might be unhappy about. And, actually, one of them looks super-plausible: this is all happening in an ordinary-Windows directory (via /mnt/c/… on WSL) and “MongoDB does not support filesystems like NFS that do not allow file locking.” So, time to put the whole thing inside WSL-land and see if it fares any better, I guess.
When the npm install option results in some errors, what I find most helpful is to try to install those things individually (where you can focus on just the errors relevant to a single thing)
So my next step if this were my machine would be:
1. look up the version of chromedriver it’s trying to install (in the package.json file)
2. I can see that it’s chromedrive@r^2.34.1
3. Try npm install chromedriver@^2.34.1
4. See what errors come up, do a google search for those errors and see if you find anything useful on stack overflow
You can resolve individual failed-to-download packages individually, and once you’ve done that for each package throwing errors, npm start should work.
Very much appreciate both giving it a try and then putting a fair chunk of effort into debugging.
Elo tried installing yesterday on Linux and didn’t actually get it up and running either, and upon reflection everyone I know who’s gotten it running locally has been using a mac. Linux should hopefully be easier to debug than Windows.
Meanwhile I’ll update this post with the “step 0”. I think once we’ve gotten a couple people who had troublesome installs to work properly I’ll do some more documentation about best-practices-for-install-troubleshooting.
npm install gave out a lot of warnings about outdated packages, I don’t know if they were talking about my preexisting environment or about something in the LW2 repo.
npm start took over half an hour before I went away, and when I came back many hours later it seemed to be stuck in a loop of constantly retrying something that was throwing an error.
I will also take a moment to grump that prestart_lesswrong.sh installs meteor, which I would rather have done myself (and which I wouldn’t have done through curl | bash). Still, I understand that having an easy setup makes people more likely to contribute, so I won’t grump too much. I would have appreciated a warning though, or a separate npm install_deps script or something.
Another thing that would make me more likely to contribute would be having an easy-to-setup test database to work with, instead of having to create users, articles etc. manually.
Good to know – we actually used to have the default Vulcan seed database, but it periodically caused issues with our testing environment. But I can add it back as a command that you have the option of running once, and maybe tweak the database parameters to be more LW-relevant (i.e. including an admin user, a sunshine, a trustLevel1 user, a curated post, etc)
Thanks! I think “get it set up on my local machine” is a pretty achieavable thing for most people and a good first step to at least remove one trivial inconvenience.
I’m interested. it looks like a fun and valuable thing to play with / work on. I also have the time to do so and am on the lookout for possible projects to work on. Barriers:
Not very experienced, so would have a learning curve on the basic things. clearer explanation for beginners or links to good stating places could be helpful, but i also don’t expect this to be too bad to tackle on my own.
I only have windows and the requirements seem to be either mac or linux. I probably would have tried setting it up locally otherwise.
Don’t have much experience with JS or react—so similarly to the first point, links to good starting places could be helpful, but figuring it out on my own probably wouldn’t be too bad.
Not sure how relevant this still is since it’s from 3 years ago, but thought I’d err on the side of showing my interest rather than not.
Definitely appreciate the show of interest. I’ve become less optimistic about open source in the past few years, but I do still think it’s good on the margin to have people fluent with the LW dev setup.
I think I can’t commit in the foreseeable future to doing tutoring or helping that much with the setup. If you were on mac/linux I’d recommend going ahead and trying to install the setup and see how it went. I’m not sure what to recommend for windows. I’ll ask other LW devs and see if they expect that to possibly-go-smoothly, or if it’s overdetermined to be a huge pain.
Now that I have a copy of the code running on my local machine, I was thinking of grabbing an issue to work on. (I can’t promise any commitment level beyond one issue yet.) I’m trying to be thorough reading what docs there are, and I’ve come across the contributing guidelines which says to check out a roadmap (a Trello board) and join a Slack channel before working on anything. The Trello board doesn’t make much sense to me and I’m not sure if either of these instructions are still important to follow, or if I really should just claim an unassigned issue with a ‘good first issue’ or ‘help wanted’ tag.
Ah, that’s out of date. For now, consider this blogpost more authoritative than anything else until I fix some of the older docs (will try to do that soon).
Also, feel free to ask any questions about any of the issues – I’m happy to spend a bunch of time helping people orient around the issues themselves and the codebase in general.
If you’re at least vaguely interested in this (even if it feels a bit intimidating, or you don’t want to commit to anything), could you reply here with a brief note about your level of interest, and anything in particular that’s acting as a barrier-to-entry?
I have the sense it may be worth investing a lot of effort into making the open source system here good, but wanted some sense of how many people might be willing to help.
I am at least vaguely interested. Possible barriers to entry in my case are (1) having other higher-priority calls on my time, (2) the machine I spend most time on being a Windows box rather than Linux or Mac (I have literally no idea whether that is actually an obstacle; I know it was for old-LW), (3) general disorganization and shortage of Round Tuits, and (4) unfamiliarity with some of the specific technologies used.
Of these, #1 and #3 probably aren’t going to go away, #2 may be a non-issue (perhaps someone can comment?), and #4 serves mostly to make #1 and #3 more severe (because it makes getting started feel like a bigger investment of time).
The most effective way (of those actually available to LW developers) to make me[1] more likely to contribute is probably to provide high-level documentation of the system—the sort of thing in the OP here, in fact—so that getting into it is as painless-in-expectation as possible.
[1] Not that making me in particular more likely to contribute should be anyone’s goal (unless maybe my own), but maybe there are others who feel the same way.
On #2, I just tried the Obvious Thing of running the commands listed in the OP on my Windows machine (ordinary Windows command prompt, not MinGW or WSL or anything of the sort). Here is what happened.
The npm install command failed. What I believe to be the first informative line of the error message said Error: Can’t find Python executable “python”, you can set the PYTHON env variable. Indeed I don’t have a PYTHON environment variable set. A bit of googling suggests that on systems where it is set it ought to point to the Python executable. So I said set PATH=C:\ProgramData\Anaconda3\python.exe which is where my Python interpreter lives, and I got the same error except that it said Can’t find Python executable “C:\ProgramData\Anaconda3\python.exe” which, since that file is definitely there, I took to mean that it failed to work in some way.
I tried doing the same from an “Anaconda prompt” (i.e., a command prompt with all environment variables set up suitably) and it failed in pretty much the same way except that it had ”.EXE” instead of ”.exe” at the end of the Python executable name it said it couldn’t find.
Perhaps we need Python 2 rather than Python 3. So I installed Python 2.7.15 (vanilla install from python.org rather than via Anaconda), set PYTHON=C:\Python27\python.exe, and tried again. This time it apparently worked, though there were a bunch of warnings.
Then npm start failed completely, because it tries to run a bash script. Oh well, never mind.
Next try: launch a WSL bash prompt, cd /mnt/c/Users/… and try again from the top. My Ubuntu-inside-Windows doesn’t have any version of Python installed by default, so sudo apt install python-minimal (which uses Python 2 rather than Python 3) before proceeding.
Now running npm install fails in a different and more immediate way: before it even tries to do anything, three error messages, two of which are … not found and the last of which is Syntax error: word unexpected (expecting “in”). I think what’s happening is that my pseudo-Linux shell is trying to run npm from my Windows installation of npm, and then getting confused by DOS-style line endings or something of the kind. (There is quite good evidence for this in the actual error messages.)
Next try: install nodejs and npm inside pseudo-Linux and try again. The result is the same, which doesn’t make any sense to me.
So, current suggestion: step 0 is “Be running Linux or macOS” for now. May also need “make sure you have Python 2 installed”?
I’ll continue trying to get it working later, but right now I’m at work and need to be doing other things :-).
If you try again, I think you can avoid needing bash. See my comment here.
Continuing attempts on WSL under Windows 10. I killed the bash prompt I had, and started a new one. This now seems to find the correct version of npm in preference to my Windows one, and npm install no longer fails instantly.
Unfortunately, it does still fail. After downloading a bunch of things, I get a bunch of errors associated with something called chromedriver. The first error message line says ERR! Linux-4.4.0-17134-Microsoft. Perhaps this means something has tried to figure out what sort of system it’s running on and doesn’t recognize what WSL reports? Possibly-informative later lines of the error message say ERR! code ELIFECYCLE and ERR! errno ENOENT. I can’t find anything in the node_modules directory relating to chromedriver; perhaps when something fails to install npm destroys the evidence? Scrolling back, I see that there’s an earlier sign of trouble: a line of the form > chromedriver@2.38.3 install [path to chromedriver module] (note: that path no longer exists in my filesystem) followed by a line of the form > node install.js followed by a blank line and then sh: 1: node: not found. After that comes a line beginning with “Vulcan” and then a big tree diagram of modules, then some dependency-related warnings, and then the errors I mentioned above.
[EDITED to add:] It turns out that on Ubuntu (which is the particular flavour of WSL I’m using) the nodejs package doesn’t provide a node executable because there’s another Ubuntu package that wants to call its executable node. So you need to install nodejs-legacy which I think just makes there be a symlink. And with that, npm install completes.
Now, of course, npm start fails. Meteor gets installed, we get a proxy started, but then three lots of Unexpected mongo exit code 100. Restarting. and some guesses at what Mongo might be unhappy about. And, actually, one of them looks super-plausible: this is all happening in an ordinary-Windows directory (via /mnt/c/… on WSL) and “MongoDB does not support filesystems like NFS that do not allow file locking.” So, time to put the whole thing inside WSL-land and see if it fares any better, I guess.
When the
npm installoption results in some errors, what I find most helpful is to try to install those things individually (where you can focus on just the errors relevant to a single thing)So my next step if this were my machine would be:
1. look up the version of chromedriver it’s trying to install (in the package.json file)
2. I can see that it’s chromedrive@r^2.34.1
3. Try
npm install chromedriver@^2.34.14. See what errors come up, do a google search for those errors and see if you find anything useful on stack overflow
You can resolve individual failed-to-download packages individually, and once you’ve done that for each package throwing errors,
npm startshould work.Very much appreciate both giving it a try and then putting a fair chunk of effort into debugging.
Elo tried installing yesterday on Linux and didn’t actually get it up and running either, and upon reflection everyone I know who’s gotten it running locally has been using a mac. Linux should hopefully be easier to debug than Windows.
Meanwhile I’ll update this post with the “step 0”. I think once we’ve gotten a couple people who had troublesome installs to work properly I’ll do some more documentation about best-practices-for-install-troubleshooting.
It didn’t work for me on linux either.
npm installgave out a lot of warnings about outdated packages, I don’t know if they were talking about my preexisting environment or about something in the LW2 repo.npm starttook over half an hour before I went away, and when I came back many hours later it seemed to be stuck in a loop of constantly retrying something that was throwing an error.I will also take a moment to grump that
prestart_lesswrong.shinstalls meteor, which I would rather have done myself (and which I wouldn’t have done throughcurl | bash). Still, I understand that having an easy setup makes people more likely to contribute, so I won’t grump too much. I would have appreciated a warning though, or a separatenpm install_depsscript or something.I’m in a similar place except for #2.
Another thing that would make me more likely to contribute would be having an easy-to-setup test database to work with, instead of having to create users, articles etc. manually.
Good to know – we actually used to have the default Vulcan seed database, but it periodically caused issues with our testing environment. But I can add it back as a command that you have the option of running once, and maybe tweak the database parameters to be more LW-relevant (i.e. including an admin user, a sunshine, a trustLevel1 user, a curated post, etc)
I am interested and going to try to set up. Not sure how much coding capacity I have or how much help I can be.
Thanks! I think “get it set up on my local machine” is a pretty achieavable thing for most people and a good first step to at least remove one trivial inconvenience.
I’m interested. it looks like a fun and valuable thing to play with / work on. I also have the time to do so and am on the lookout for possible projects to work on. Barriers:
Not very experienced, so would have a learning curve on the basic things. clearer explanation for beginners or links to good stating places could be helpful, but i also don’t expect this to be too bad to tackle on my own.
I only have windows and the requirements seem to be either mac or linux. I probably would have tried setting it up locally otherwise.
Don’t have much experience with JS or react—so similarly to the first point, links to good starting places could be helpful, but figuring it out on my own probably wouldn’t be too bad.
Not sure how relevant this still is since it’s from 3 years ago, but thought I’d err on the side of showing my interest rather than not.
Definitely appreciate the show of interest. I’ve become less optimistic about open source in the past few years, but I do still think it’s good on the margin to have people fluent with the LW dev setup.
I think I can’t commit in the foreseeable future to doing tutoring or helping that much with the setup. If you were on mac/linux I’d recommend going ahead and trying to install the setup and see how it went. I’m not sure what to recommend for windows. I’ll ask other LW devs and see if they expect that to possibly-go-smoothly, or if it’s overdetermined to be a huge pain.
Now that I have a copy of the code running on my local machine, I was thinking of grabbing an issue to work on. (I can’t promise any commitment level beyond one issue yet.) I’m trying to be thorough reading what docs there are, and I’ve come across the contributing guidelines which says to check out a roadmap (a Trello board) and join a Slack channel before working on anything. The Trello board doesn’t make much sense to me and I’m not sure if either of these instructions are still important to follow, or if I really should just claim an unassigned issue with a ‘good first issue’ or ‘help wanted’ tag.
Ah, that’s out of date. For now, consider this blogpost more authoritative than anything else until I fix some of the older docs (will try to do that soon).
Here are the ‘good first issues’ :
https://github.com/Discordius/Lesswrong2/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
Also, feel free to ask any questions about any of the issues – I’m happy to spend a bunch of time helping people orient around the issues themselves and the codebase in general.
As far as I know, go claim an issue.