Crates who have yanked all their versions should only return name, owners, and that it's yanked

[carols10cents]

In search results and on the crate's page, we should be displaying crates with all of their versions yanked (henceforth referred to as "yanked crates") differently (#145), but the backend needs to tell the frontend that a crate is in this state.

Instructions for fixing this:

• Add a field named all_versions_yanked to EncodableCrate and everywhere we create EncodableCrate instances, set that field to false if there exists any non-yanked versions for this crate. I'd recommend doing a select(exists()) query using diesel similar to this query
• If we're constructing an EncodableCrate instance for a yanked crate, these fields should be changed too:
  • badges, description, homepage, documentation, and repository should be None
  • max_version should be "0.0.0"

Some other fields, like keywords and categories, are used for search/crate lists, and this issue isn't going to change search results, so I think we should still display why a crate showed up in a particular list of crates.

[seanlinsley]

I'd like to work on this. It'll be my first Rust code contribution! Thanks for making it so accessible to new people ❤️ I actually got here from the RustConf keynote on YouTube.

[carols10cents]

Hi @seanlinsley!!! It's awesome to have you!! Please let me know if you have any questions ❤️

[seanlinsley]

When running diesel migration run I noticed this error:

NOTICE:  table "schema_migrations" does not exist, skipping

The backend server appears to boot, though some tables are missing when running the tests:

---- category::tests::category_toplevel_includes_subcategories_in_crate_cnt stdout ----
  thread 'category::tests::category_toplevel_includes_subcategories_in_crate_cnt' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"categories\" does not exist")', src/libcore/result.rs:860:4

---- category::tests::category_toplevel_applies_limit_and_offset stdout ----
  thread 'category::tests::category_toplevel_applies_limit_and_offset' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"categories\" does not exist")', src/libcore/result.rs:860:4

---- category::tests::category_toplevel_orders_by_crates_cnt_when_sort_given stdout ----
  thread 'category::tests::category_toplevel_orders_by_crates_cnt_when_sort_given' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"categories\" does not exist")', src/libcore/result.rs:860:4

---- category::tests::category_toplevel_applies_limit_and_offset_after_grouping stdout ----
  thread 'category::tests::category_toplevel_applies_limit_and_offset_after_grouping' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"categories\" does not exist")', src/libcore/result.rs:860:4

---- category::tests::category_toplevel_excludes_subcategories stdout ----
  thread 'category::tests::category_toplevel_excludes_subcategories' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"categories\" does not exist")', src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- keyword::tests::dont_associate_with_non_lowercased_keywords stdout ----
  thread 'keyword::tests::dont_associate_with_non_lowercased_keywords' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "relation \"keywords\" does not exist")', src/libcore/result.rs:860:4


failures:
    category::tests::category_toplevel_applies_limit_and_offset
    category::tests::category_toplevel_applies_limit_and_offset_after_grouping
    category::tests::category_toplevel_excludes_subcategories
    category::tests::category_toplevel_includes_subcategories_in_crate_cnt
    category::tests::category_toplevel_orders_by_crates_cnt_when_sort_given
    keyword::tests::dont_associate_with_non_lowercased_keywords

test result: FAILED. 12 passed; 6 failed; 0 ignored; 0 measured; 0 filtered out

The setup instructions say that cargo test should run the migrations automatically. Perhaps that's broken?

A caveat was that I ran diesel migration run (for the dev env) twice before it ran successfully (because of misconfiguration). Perhaps they modified some global state before exiting?

These were the exact errors:

# I hadn't set up `.env` yet

$ diesel migration run
The --database-url argument must be passed, or the DATABASE_URL environment variable must be set.

# Homebrew's install doesn't provide a postgres user

$ diesel migration run
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ConnectionError(BadConnection("FATAL:  role \"postgres\" does not exist\n"))', src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[seanlinsley]

Indeed, the test database has no tables in it.

[seanlinsley]

Oddly diesel migration run --database-url cargo_registry_test doesn't do anything.

[sgrif]

It's a clap bug. clap-rs/clap#978 Unfortunately you need to do diesel migration --database-url=... run. Your database URL should probably be postgres://localhost/cargo_registry_test

[sgrif]

If you have TEST_DATABASE_URL set in a .env file, just running cargo test should migrate it automatically