Skip to content

Conversation

@jyn514
Copy link
Member

@jyn514 jyn514 commented Nov 2, 2019

  • Add a flag to make it possible
  • Add documentation to the readme (since docker-compose makes it not very intuitive)

Note: this breaks backwards compatibility for build_package. This could be avoided by adding a private build_package_impl function but that seems ugly :/ I'm open to suggestions on how to make this backwards compatible.

NOTE: this breaks backwards compatibility for build_package
@jyn514
Copy link
Member Author

jyn514 commented Nov 2, 2019

Motivation: someone asked in the docs-rs channel on discord whether they could see what docs.rs would do with a given package without publishing it on crates.io. As it currently stands, the answer was no. I would have found this useful in the past as well, so I added it.

@jyn514
Copy link
Member Author

jyn514 commented Nov 2, 2019

So after testing this locally I found that this crashes the web server once you try to actually load one of the local crates:

thread '<unnamed>' panicked at 'error retrieving column 4: Error(Conversion(WasNull))', /root/.cargo/registry/src/github.202132.xyz-1ecc6299db9ec823/postgres-0.15.2/src/rows.rs:201:31
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.202132.xyz-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.202132.xyz-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: postgres::rows::Row::get
  10: cratesfyi::web::releases::get_releases
  11: <F as iron::middleware::Handler>::handle
  12: <alloc::boxed::Box<dyn iron::middleware::Handler> as iron::middleware::Handler>::handle
  13: router::router::Router::handle_method
  14: <router::router::Router as iron::middleware::Handler>::handle
  15: iron::middleware::Chain::continue_from_handler
  16: <iron::middleware::Chain as iron::middleware::Handler>::handle
  17: <alloc::boxed::Box<dyn iron::middleware::Handler> as iron::middleware::Handler>::handle
  18: <cratesfyi::web::CratesfyiHandler as iron::middleware::Handler>::handle
  19: <iron::iron::RawHandler<H> as hyper::server::Handler>::handle
  20: hyper::server::Worker<H>::handle_connection
  21: hyper::server::listener::spawn_with::{{closure}}

The root cause is that local packages were never released, so they don't have a release time. The fix is to make Release.release_time nullable.

@jyn514
Copy link
Member Author

jyn514 commented Nov 2, 2019

Actually a better idea is to keep the time non-nullable and set the release time for local packages to the build time

@jyn514
Copy link
Member Author

jyn514 commented Nov 4, 2019

This is ready for review.

@pietroalbini
Copy link
Member

This looks great! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants