uv panics when trying to create more than one RequirementsSource from a file without -r

[slafs]

uv panics when trying to create more than one RequirementsSource instance in the from_package method when the given name is a file.

The below steps (ran inside python:3.11-alpine container, but the same happens on OSX 14.4.1) will reproduce the crash:

# pip install uv
Collecting uv
  Downloading uv-0.1.29-py3-none-musllinux_1_2_x86_64.whl.metadata (26 kB)
Downloading uv-0.1.29-py3-none-musllinux_1_2_x86_64.whl (11.5 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 11.5/11.5 MB 8.1 MB/s eta 0:00:00
Installing collected packages: uv
Successfully installed uv-0.1.29
# echo cowsay > ./req1.txt
# echo cowsay > ./req2.txt
# uv pip install req1.txt req2.txt
✔ `req1.txt` looks like a local requirements file but was passed as a package name. Did you mean `-r req1.txt`? · yes
thread 'main' panicked at crates/uv-requirements/src/sources.rs:98:75:
called `Result::unwrap()` on an `Err` value: Ctrl-C error: Ctrl-C signal handler already registered
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This happens when trying to prompt the user to auto convert pip install file.txt into a proper -r form (which is a very nice feature, that I'm planning to utilize often BTW 👍).

With one file everything's fine, but when passing more than one (e.g. with a glob),
uv panics, because it tries to unwrap on an error from the ctrlc::set_handler call.
The error apparently happens when trying to set more than one handler for Ctrl+C.

This workaround works for me:

diff --git a/crates/uv-requirements/src/confirm.rs b/crates/uv-requirements/src/confirm.rs
index 3b111d33..e8737b73 100644
--- a/crates/uv-requirements/src/confirm.rs
+++ b/crates/uv-requirements/src/confirm.rs
@@ -6,7 +6,7 @@ use console::{style, Key, Term};
 /// This is a slimmed-down version of `dialoguer::Confirm`, with the post-confirmation report
 /// enabled.
 pub(crate) fn confirm(message: &str, term: &Term, default: bool) -> Result<bool> {
-    ctrlc::set_handler(move || {
+    let handler_set = ctrlc::set_handler(move || {
         let term = Term::stderr();
         term.show_cursor().ok();
         term.flush().ok();
@@ -17,7 +17,13 @@ pub(crate) fn confirm(message: &str, term: &Term, default: bool) -> Result<bool>
         } else {
             130
         });
-    })?;
+    });
+
+    // silence MultipleHandlers error from ctrlc
+    match handler_set {
+        Ok(_) | Err(ctrlc::Error::MultipleHandlers) => {},
+        Err(e) => return Err(e.into()),
+    }
 
     let prompt = format!(
         "{} {} {} {} {}",

Which I would be more than happy to turn into a PR 🤞.

However, looking at the set_handler docs from ctrlc it looks like it shouldn't ever return MultipleHandlers (there's a try_set_handler function for that) and it should overwrite the existing handler 🤷.

I've asked this question in Detegr/rust-ctrlc#118

[charliermarsh]

Thanks!

[charliermarsh]

My read is that set_handler will return an error if called twice. But if there's an existing handler set by the system, it will overwrite it. So I think we should proceed with your change. PR welcome.