New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed #29026 -- Added --scriptable option to makemigrations. #14751
Fixed #29026 -- Added --scriptable option to makemigrations. #14751
Conversation
44fac26
to
11b9229
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The direction we're going elsewhere is to make log()
a method that accepts a msg
argument. See e.g.
django/django/db/backends/base/creation.py
Lines 29 to 30 in 8208381
def log(self, msg): | |
sys.stderr.write(msg + os.linesep) |
and
Lines 672 to 683 in 8208381
def log(self, msg, level=None): | |
""" | |
Log the given message at the given logging level. | |
A verbosity of 1 logs INFO (the default level) or above, and verbosity | |
2 or higher logs all levels. | |
""" | |
if self.verbosity <= 0 or ( | |
self.verbosity == 1 and level is not None and level < logging.INFO | |
): | |
return | |
print(msg) |
My thoughts would be to add an initial commit that adds a log()
method and makes all stderr / stdout output go through that. (Whether log()
uses stderr or stdout could be controlled centrally in that method.) Then, rather than structured_output
, I would add a property whose job is to return whether log()
is using stderr
. If it's using stderr
, then the "output" code lines could switch to using stdout
instead of log()
. The thing with structured
is that text lines aren't that structured. To me that sounds more like json. It seems like the user-facing option should be more about whether logging should go to stderr. Then the non-logging ("output") lines would continue to go to stdout as is.
Also, in the case that logging is going to stderr, I think you'd still want to log the output lines using log()
as a message, so that info would be available both in the diagnostic stderr logs, as well as the output.
Very reasonable--I'll think about a name for this option.
My thought process was this: merely switching the output to stderr is achievable today: you simply subclass the command and set
So I'm a little hesitant to do to this, because then we're making
Agreed, I made sure this was the case. Any thoughts on the ticket-29470 stuff? If we have design questions about ticket-29026 I could ask the fellows to re-triage 29470 and move it to a separate PR to keep it moving. |
btw, thanks for the review, @cjerdonek! And it looks like I need to liberalize one of the tests to pass on Windows. |
Maybe Everything but the last line going to stderr, last line to stdout:
|
This didn't feel right when I wrote it, and indeed--it's easier than that, there's The drift of my earlier comment was that I would be hesitant to rework the documented API we have for that. I see the issue as more defining wanting separate logs, period. |
11b9229
to
4ace319
Compare
To respond to one point now:
I think making |
I have to admit, this did occur to me when I was writing it, and if you also noticed it, lots of folks will. :-O
That's a good reason.
I guess I wasn't looking at it that way. 👍🏻 Thanks for the quick feedback, and I'll have a look at implementing a |
b6ab486
to
59034a4
Compare
Maybe |
At a glance, I would be a bit worried it implies setting |
I think there's an argument the mode should imply Either way, I think you'd want to document in the help whether |
Reading and thinking more about Python's Also, on this question:
After reading and thinking about it, I think it should be re-opened and handled separately. I can go ahead and add a comment to the ticket. |
Hello @francoisfreitag -- I noticed you have a WIP branch for ticket-21429 implementing logging for each of the management commands. As you can see above, Chris is making the good case that to move this PR forward, I should do something similar for |
@jacobtylerwalls By the way, regarding the django/django/contrib/staticfiles/management/commands/collectstatic.py Lines 207 to 212 in 8208381
It will be of help here independent of that ticket. |
Hi @cjerdonek, Thanks for the ping! Fixing ticket-21429 is pretty time consuming and personal life has been busy (and will be for at least a few months). My employer is not interested in sponsoring the work for now, so it’s all on my personal time. Basically, my todo list includes:
#13853 is just a very early step, introducing tools I would like to use for the logging PR. I’m afraid there are weeks of work remaining before my branch can be put up for review, and I am not able to commit to a timeline. |
Thanks for the update. I certainly wouldn't ask you to commit to a timeline! I was just merely curious if I should try to conform to any likely pending changes. I think I have enough to go on for now. Good luck with everything, and be well. --Jacob |
2fdb919
to
7acab6a
Compare
Thanks for the design guidance @cjerdonek , that was very helpful. I haven't squashed/reordered commits yet, and I am still thinking about #14751 (comment), but I wanted to ask if you thought these changes were looking right-track to you. I'd be grateful if you had time for a re-review. I didn't as of yet tackle a refactor of how verbosity is tracked. There's enough going on (and I feel like this PR is already two or so.) Speaking of which, thanks for commenting on ticket-29470. |
Hi @jacobtylerwalls, yes, I think there's already a lot going on, so I'd encourage you to start breaking this up into smaller PR's. The first one I'd recommend is a refactoring PR that just adds a |
10f4b4f
to
6ee770a
Compare
53e7e8f
to
03ad4d0
Compare
03ad4d0
to
b93f083
Compare
ae42c87
to
b3ef6f8
Compare
b3ef6f8
to
44eeab3
Compare
Done! 🎉 |
d3ddf57
to
18c7a70
Compare
Summary: Adds
That's all the diff does, it's just bloated because the interactive questioner was using Could also be good to rebase after #15212. |
7899bcc
to
ef8baae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacobtylerwalls Thanks 👍 Can we move adding prompt_output
to the InteractiveMigrationQuestioner
to a separate PR?
7952bab
to
04b14c2
Compare
1298296
to
02f91fb
Compare
02f91fb
to
46fa756
Compare
@jacobtylerwalls Thanks 👍 I added writing a path of generated migration file to the |
4cb7892
to
87aca40
Compare
87aca40
to
6f78cb6
Compare
@felixxm Thanks for the updates and the additional test! |
ticket-29026 desires to separate logging from a simple list of filepaths created in
makemigrations
.--scriptable
that will 1. divert all current logging to stderr and 2. log only the filepaths of created migration files to stdout, one per line (without leading spaces and styling)--noinput
mode is still necessary to suppress input completely, otherwise interactive prompts go to stderr when--scriptable
is usedEDIT: moved ticket-29470 solution to #14805
All of this logging can be silenced with
--verbosity 0
: no changes in this respect.