Skip to content

Conversation

@pydanny
Copy link
Contributor

@pydanny pydanny commented May 13, 2025

  • Removed rich as a dependency
  • Activity is published using the built-in print statement
  • In place of red+bold console.log statements, we're using sys.stderr.write.

@pydanny pydanny requested review from algal and jph00 May 13, 2025 13:12
@algal
Copy link
Contributor

algal commented May 13, 2025

Great. This will resolve #2 .

I'll review today.

Copy link
Contributor

@jph00 jph00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor suggestions (some of them not directly related to the PR, since I haven't seen this code before.)

@pydanny pydanny closed this May 26, 2025
@pydanny pydanny reopened this May 26, 2025
@jph00
Copy link
Contributor

jph00 commented Jun 7, 2025

@algal do you have a chance to look thru this and update/merge it?

@algal
Copy link
Contributor

algal commented Jun 9, 2025

@jph00 will handle today with other fastmigrate release work.

@algal algal requested a review from jph00 June 9, 2025 18:35
@algal
Copy link
Contributor

algal commented Jun 9, 2025

@jph00 I'm presuming this is okay and doesn't strictly need a re-review from you, since the last commits address all your comments. But I pushed the re-review button anyway in just in case.

However, I'm targeting a release by EOD, so if you don't have time to check it out by then, I will assume this is fine and merge as part of that release process.

console.print(f"[bold red]Error[/bold red] executing Python script {script_path}:")
console.print(e.stderr.decode(), style="red")
print(f"Error executing Python script {script_path}:", file=stderr)
sys.stderr.write(e.stderr.decode())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my curiosity - why not use print here?

Copy link
Contributor

@algal algal Jun 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My very brief thinking here was that since the string being printed was not UI copy defined in the code, but rather was a value being provided by other bits of API, then sys.stderr.write communicated more clearly to the reader that this code is simply conveying the value directly without any modifications, such as the newline automatically added by print.

Of course I could suppress that and do print(e.stderr.decode(),end='',file=stderr). This has the pro of being more consistent with the other uses of print, but the con of being a little more roundabout.

So this seemed a little cleaner? But if I'd put more sugar in my coffee in the morning, I probably would have gone the other way. Borderline case!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, you then immediately print a newline on the next line, so you end up with two lines instead of one IIUC…

FWIW, for this reader at least, sys.stderr.write communicated to me that you're doing something special/different, and I should try to figure out why! :D

@jph00
Copy link
Contributor

jph00 commented Jun 9, 2025

lgtm @algal :)

@algal algal merged commit 3cf6bef into main Jun 9, 2025
8 checks passed
@algal algal deleted the remove-rich branch June 9, 2025 18:50
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.

4 participants