I'm interested!

I'm also interested in always writing to a log file in a temporary directory unless it's disabled? Like UV_LOG_DIR? I'm not sure what this would look like in practice.

@zanieb I am interested in working on this, here is the initial idea/ requirements I have when thinking about this:

1. Add a global options --log (can also be set using an environment variable , and no-log argument if that is set not logged).
2. If log path not set it should default to logs directory in the root folder
3. From the research I have done tracing-appender crate sounds like a great choice to write to the files and it offers the feature for rolling logs by frequency to prevent the log file size from being too big.
4. I am thinking everything that the logger would write if it's writing in the the most verbose way should be written to file
5. If it is part of the project the log directory should be in the root of the project otherwise a global log directory

Let me know if you have other requirements or considerations in mind

Hi! I think this makes sense, though I have a few comments:

If log path not set it should default to logs directory in the root folder

Just remember this also needs an equivalent on macOS and Windows. Is there an XDG specification?

If it is part of the project the log directory should be in the root of the project

I don't love the idea of in-project logs, unless we have a dedicated .uv directory or similar. Out of project seems like a safer start.

I am thinking everything that the logger would write if it's writing in the the most verbose way should be written to file

I think trace-level logs may be too much? I'm not sure though. We may need to adjust this based on the practical experience. We should probably allow configuration of levels, e.g., via UV_LOG_LEVEL?

From the research I have done tracing-appender crate sounds like a great choice to write to the files and it offers the feature for rolling logs by frequency to prevent the log file size from being too big.

Should we write to a single file? Or a file per command invocation? I lean towards the latter.

@konstin and @BurntSushi may have opinions about the best way to do this.

I think for me, it kinda depends on how folks want to use this.

The initial proposal is really simple: the user provides a path to a file, and uv appends logs to it. There's probably some decision making around figuring out the default log level when none is specified and --log is given, but it otherwise seems kinda dumb (in a good way?) to me.

But if we get into log file rotation, separating logs by command invocation, separate ways for setting the log level (how would that interact with RUST_LOG for example), then the surface area here gets a lot bigger and more complex.

So I guess for me, I start with, in what cases do users want to use something other than RUST_LOG=debug uv ... &> /tmp/log?

My motivation is to not need to enable logging and re-run a command to see failures. I want to be able to say "See for more logs" on failure — sort of in the vein of #8351.

My motivation is to not need to enable logging and re-run a command to see failures. I want to be able to say "See for more logs" on failure — sort of in the vein of #8351.

That's also my use case, i.e. directing users to a detailed log file in case installation fails for any reason.

@zanieb I have been working on this issue and on the requirements I am unsure about is when using file logs when running snapshot tests do you think it is so that we break the current snapshot tests that end in failure by adding a "See for more logs" to the snapshot or omit doing that when running snapshots

I want to be able to say "See for more logs" on failure — sort of in the vein of #8351.

It's fine to add content to the existing snapshots.

cc @Gankra for general awareness about output changes