Document in the README instructions for backend setup that cmake is also required

[carols10cents]

At least on OSX. (and it can be installed from homebrew there).

I don't think I ever ran into this because I had cmake installed for something else. Travis definitely apt-gets it though.

[baileyn]

"On fedora, to get setup, I had to install postgres-devel as well as postgres, openssl-devel, cmake, and jump through a few hoops with fedora. In the end it all worked.

[baileyn]

In the README, there's stuff about OpenSSL when you're running cargo build. Maybe it should be further up?

[baileyn]

Make it clearer why there's a need (or the lack thereof) to make a ~/.cargo/config

[baileyn]

After I got back to my dorm I started installing all of the software I needed on my home computer. I went ahead and made a note about all of the steps I had to go through on Fedora 25; hopefully they can come in use.

Frontend Installation

1. I had to do was actually install npm using: sudo dnf install npm
   • I think it would be nice before the Working on the Frontend section to have a Requirements section that documented the binaries used during installation. These include (on a fresh Fedora 25 installation): npm, postgresql-server (Maybe link to the Fedora WIKI installation guide, it is good for this part. Towards the bottom of the wiki, under the header pg_hba.conf, I discovered that it explicitly states the solution to the problem we were running into during the bug-squashing event located here), postgresql-devel, openssl-devel, and finally cmake.
2. When using npm to install yarn, it was important to use sudo.
   • I'd agree this is common knowledge, but depending how user-friendly the README should be, it would be nice to change it's command in the README to explicitly state sudo npm install -g yarn rather than just npm install -g yarn

Backend Installation

1. As I mentioned earlier, with installing postgresql-server and postgresql-devel it's a good idea in my opinion to link to the wiki, but also explicitely state the need for postgresql-devel. It's not listed on that wiki page.
   • As I said above, the wiki has a part under pg_hba.conf on fixing the primary database issue we ran into at WVU. I set all the permissions to trust, but I don't believe that's the BEST solution ever. I remember Jake and I set them to md5, but that required us to also use the database urls like postgres://postgres:password@localhost/cargo_registry[_test], but then the password is just in plain text in the file. I'm sure there's work arounds, but I haven't gotten that far.
2. Under step 2, the user is told to cp .env.sample .env, but it's never explicitly stated when to actually source this file. I think it would make it more clear to state when to actually source this file. I think it would make the most sense to talk about it after explaining how to setup the DATABASE_URL and TEST_DATABASE_URL exports.

Running tests (for the backend)

1. I think it would be nice in the first step to possibly mention that you can create the databases from the command line via createdb cargo_registry_test. It's also important to note on Fedora 25 I had to sudo su - postgres in order to initially setup the passwords and other administrative tasks under psql. There may be another way around it, but that's the path I took.
2. On step two, this is where I'd mention the need to source after modifying the .env file. Maybe just mention it as a blanket term somewhere in the README: "Anytime you create or modify the .env file, be sure to source it afterwards."
3. I ran into the problem where I needed to install openssl-devel. This was as easy as just sudo dnf install openssl-devel.
4. I also had to be sure cmake was installed at this point. Again, it was a simple task by just running sudo dnf install cmake, but I feel like for completeness I should include it.

Hosting crates locally

1. Again, createdb cargo_registry could be used here and be a little more simple, but I don't know if it's a major concern.
2. Another instance of the need to source the .env file is right here. Again, I don't know if it should be reiterated all that much, but I do think it needs to be mentioned somewhere.
3. Right here is where I was instructed to modify ~/.cargo/config. It's mentioned to not modify the file YET, but it is instructed to do the modification in step 5.
4. It's mentioned here about the openssl headers being required. I think this is the same issue I ran into during the testing phase.
5. This is who told me to modify the config file :)

These are all of the things I explicitly noted during the installation. I now have a working backend and frontend on my home computer that is using my local database for the crates. Just like the initial setup required for the bug-squashing event.

[carols10cents]

OMG this is amazing @baileyn!!!!! You've just saved me a LOT of work, and it's going to make the setup instructions so much better ❤️ ❤️ ❤️ I'm going to work on incorporating all of this in the next few days!!!

[baileyn]

@carols10cents I'm glad I could help! If there's anything I can do to help out more with this just let me know. In the mean time, I'm going to continue reading and try to find an issue I can tackle.

[carols10cents]

Hey @baileyn! I finally have a pull request up to make the instructions better: #687

I decided to try and keep it mostly platform-agnostic, so I left out some of the fedora-specific instructions for problems we ran into at WVU, but I did put in some links.

I just tried following the instructions on an Ubuntu VM and I got everything working-- if you have a chance, could you try starting from scratch on fedora and following the instructions here to see if they're better or if there are still holes?

On step two, this is where I'd mention the need to source after modifying the .env file. Maybe just mention it as a blanket term somewhere in the README: "Anytime you create or modify the .env file, be sure to source it afterwards."

I think we actually screwed up at WVU with this :( If I remember correctly, I think we were hitting the "must have GIT_REPO_URL defined" error, and I suggested sourceing .env, which was the wrong fix. Then, once yinz had sourced once, the env vars in the environment took precedence over the ones in .env, which is why we had to keep sourcing .env.

I have another pull request in that changes .env.sample to look like this which I think should solve that problem. So when you get to the instructions about copying .env.sample, please copy the contents of that version instead :)

Again, I'm so grateful for your feedback from before, if you don't have time to run through all of this again, no worries!!! You've already helped out a ton :)

[baileyn]

I absolutely will! I am about to go to work, but I'll definitely go through the new steps.