This is quite a common workflow when I want documentation on crate 'foo':

1. go to crates.io
2. search for foo
3. click the correct result
4. click the 'documentation' link

It would be faster if it wasn't necessary to first click the result (step 3) to get the documentation link (also for home and repo, though less important).

Hiiii! This is the first part of adding categories to crates.io!

What this PR does

• A binary sync-categories, which will take the list of categories in src/categories.txt and add or remove categories from the database as needed to make the database match the categories. This way, the list of available categories can be changed via pull request to this repo. This will need to be run on the server after the text file changes; once we have some categories I think it'd be good to run this automatically after deploying (after migrate runs) so that no one has to remember to do it.
• A /categories page not yet linked from anywhere that displays all the categories in alphabetical order
• A /categories/whatever page that will list all the crates in a category
• If a crate has categories, they will be listed on that crate's page in the sidebar under Keywords
• If categories are specified in the metadata uploaded with a new crate request from cargo, they will be added to the crate. I have not yet added this functionality to cargo.

Testing this PR

$ cargo build $ cargo run --bin migrate $ cargo run --bin sync-categories $ cargo run --bin server

Start the frontend as well (Note: I had to use ember server --proxy http://127.0.0.1:8888 instead of yarn run start:local with the latest version of yarn in order to actually use my local backend, I'm investigating why this is the case)

• You should be able to go to /categories and see 2 categories, "Attempt" and "Test"
• You should be able to click on those categories and see 0 crates
• Publish a crate to your local crates.io (I had to comment out code uploading to s3 since I didn't want to do that)
• For now the way to add a crate to a category, since cargo does not yet support this, is to go into the database and add a record in crates_categories joining your crate to a category
• You should see your crate on that category's page
• You should see the category on the crate's page (might have to do a shift-reload because of ember caching)

Deploying this PR

It should be totally fine to deploy this PR to crates.io. Nothing links to /categories, and cargo does not publish category metadata yet-- and neither cargo nor crates.io will complain if a crate is not in any categories.

After this PR is merged

• I will start a PR to categories.txt where we can bikeshed what we actually want the initial set of categories to be
• I will make changes to cargo to publish category data specified in Cargo.toml
• I will have some way of warning on cargo publish if your Cargo.toml specifies a category that is not a valid category (i'm not entirely sure exactly how to implement this yet)

Right now cargo_registry::env panics if there isn't a value set for an env var, so you can't run the server locally unless you set values for everything in .env.

If you're just working on part of the backend that you don't need users logged in for, there's no reason to have to set up github tokens and all that.

I tried to make this easier to set up by setting the values in .env.sample to "", which gets around the panic, but apparently that caused problems with zsh.

I think it'd be better to have another function, like env_with_default or something, and maybe warn that functionality that needs that env var isn't going to work?

I'm happy to do this, just not right this second, so I wanted to open this to remind me (and maybe entice someone else to do it, i don't think it would be very hard #famouslastwords)

I just published ring 0.6.0-alpha so I could get some pre-release feedback. I expected that the page at https://crates.io/crates/ring would continue to say ring = "0.5.3" bit instead it says ring = "0.6.0-alpha". If somebody goes through the trouble to use the -alpha/-beta modifiers then they probably don't want the average user of their crate to use that version.

https://crates.io/crates/error-chain/0.5.0

https://github.com/brson/error-chain/blob/6af2cc5be10f2ee848978ea9b168680c5fe48a23/Cargo.toml

toml authors = [ "Brian Anderson <[email protected]>", "Paul Colomiets <[email protected]>", "Colin Kiegel <[email protected]>"]

Also observed with other multi-author crates like backtrace and hyper.

Edit: If I'm reading the code right the order is whatever the SQL query returns. If so, and if you don't want to preserve the Cargo.toml order, perhaps they could be ordered alphabetically? It's not a big deal anyway.