Repository: nvaccess/nvda

Issue:
NVDA should log its version number immediately, at all log levels
Note: edited to reflect that NVDA does log version, just not soon enough IMO.

### Is your feature request related to a problem? Please describe.

Not a specific one, but to help debugging problems in general, and when doing software testing, I would like to see NVDA's version number in the log, *as soon as possible*. I think it should be included at the lowest level of logging where something is logged, which I believe is currently the "disabled" level.

### Describe the solution you'd like

The log currently provides this *as its first entry*:

> INFO - __main__ (05:29:56.973):
> Starting NVDA

I would like to see this replaced with something like:

> INFO - __main__ (05:29:56.973):
> Starting NVDA, version alpha-17780,40bef374

### Describe alternatives you've considered

There aren't any that I know of. I am used to working with Unix systems, where most everything that generates a log meant for debugging, includes the program's version *unconditionally*.

### Additional context

When attempting to debug NVDA issues, it is sometimes useful to run several versions of NVDA sequentially. *(edit)* If NVDA is not set to at least info level logging in its saved config, or started with the necessary CLI option, and is only later set to a more detailed log level, the version is never logged.
(If started with a log level such as "warning" (--log-level=30), the version is not logged either, but neither is much else. Odd, since the "disabled" log level logs more, but I digress).

I had a case recently, where a failure mode was causing NVDA not to produce any log file under a particular circumstance. It thus became difficult to determine which of the files I was looking at, had been generated by which version of NVDA: the current one that just ran, or the one that ran before that because this one didn't clean up that one's log into nvda-old, etc.
Since these were different versions of NVDA, if the first or second log entry had included the NVDA version number, as most software does, this situation would have been a non-issue.



Discussion:
The required information is already present in the log. In my case it's the 10th line from the top as follows:

>NVDA version alpha-17780,40bef374



When nvda is unable to open the log to write it opens a log actually in the 
folder where nvda ran. Perhaps this is the place for such a thing, as at the 
moment it does just contain some general error info, like unable to write to 
etc.

This sort of error seems to occur after an update when for whatever reason 
Windows fails to release nvda.log fast enough and a windows error occurs 
stopping nvda from reloading.
 Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- 
From: "Luke Davis" <notifications@github.com>
To: "nvaccess/nvda" <nvda@noreply.github.com>
Cc: "Subscribed" <subscribed@noreply.github.com>
Sent: Monday, June 24, 2019 11:06 AM
Subject: [nvaccess/nvda] NVDA should include its own version number in logs 
(#9803)


> ### Is your feature request related to a problem? Please describe.
>
> Not a specific one, but to help debugging problems in general, and when 
> doing software testing, I would like to see NVDA's version number in the 
> log. I think it should be included at the lowest level of logging where 
> something is logged, which I believe is currently the "disabled" level.
>
> ### Describe the solution you'd like
>
> The log currently provides this:
>
>> INFO - __main__ (05:29:56.973):
>> Starting NVDA
>
> As its first line. I would like to see this replaced with something like:
>
>> INFO - __main__ (05:29:56.973):
>> Starting NVDA, version alpha-17780,40bef374
>
> ### Describe alternatives you've considered
>
> There aren't any that I know of. I am used to working with Unix systems, 
> where most everything that generates a log meant for debugging, includes 
> the program's version as a matter of course.
>
> ### Additional context
>
> When attempting to debug NVDA issues, it is sometimes useful to run 
> several versions of NVDA sequentially.
> I had a case recently, where a failure mode was causing NVDA not to 
> produce any log file under a particular circumstance. It thus became 
> difficult to determine which of the files I was looking at, had been 
> generated by which version of NVDA: the current one that just ran, or the 
> one that ran before that because this one didn't clean up that one's log 
> into nvda-old, etc.
> Since these were different versions of NVDA, if the first or second log 
> entry had included the NVDA version number, as most software does, this 
> situation would have been a non-issue.
> I had noticed this in debugging exercises before, but this was the first 
> time it was so obviously a problem which I had to work around.
>
> -- 
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/nvaccess/nvda/issues/9803 


I see.

Yes, it is there, but I still maintain that:

1. It should appear almost immediately--before NVDA tries to load configurations, or starts logging other things.
    + In theory, although I don't know enough about the logging system to be sure, something could go wrong in the config loading or other processes, and the info call that logs the version might never be generated. Don't know how realistic that is.
2. That version is only logged, if your saved configuration includes info level logging or higher. If you initiate debugging or other logging after startup from a logging "disabled" state, you never get the info message about the version, which was why I never saw it in my other runs.
    + See the attached log from 2019.1.1 for an example of this.

So unless I am wrong again about some part of this, I revise my request to having the version logged immediately, and at every level, including "disabled" (which still does log the startup).
[no_version-2019.1.1.txt](https://github.com/nvaccess/nvda/files/3320406/no_version-2019.1.1.txt)

Hi, I see. In theory, it is possible to move things around (using buildVersion module rather than versionInfo). CC @MichaelDCurran

 

From: Luke Davis <notifications@github.com> 
Sent: Monday, June 24, 2019 3:46 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [nvaccess/nvda] NVDA should include its own version number in logs (#9803)

 

I see.

Yes, it is there, but I still maintain that:

1.	It should appear almost immediately--before NVDA tries to load configurations, or starts logging other things. 

*	In theory, although I don't know enough about the logging system to be sure, something could go wrong in the config loading or other processes, and the info call that logs the version might never be generated. Don't know how realistic that is.

2.	That version is only logged, if your saved configuration includes info level logging or higher. If you initiate debugging or other logging after startup from a logging "disabled" state, you never get the info message about the version, which was why I never saw it in my other runs. 

*	See the attached log from 2019.1.1 for an example of this.

So unless I am wrong again about some part of this, I revise my request to having the version logged immediately, and at every level, including "disabled" (which still does log the startup).
no_version-2019.1.1.txt <https://github.com/nvaccess/nvda/files/3320406/no_version-2019.1.1.txt> 

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://github.com/nvaccess/nvda/issues/9803?email_source=notifications&email_token=AB4AXEBQUJMLMIUAQSBA3SLP4CQXLA5CNFSM4H25BTS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYMQ2EI#issuecomment-504958225> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4AXEFQKZSG5KNWNB7HQJDP4CQXLANCNFSM4H25BTSQ> .



Resolving patch:
diff --git a/source/core.py b/source/core.py
--- a/source/core.py
+++ b/source/core.py
@@ -1,9 +1,9 @@
 # -*- coding: UTF-8 -*-
-#core.py
-#A part of NonVisual Desktop Access (NVDA)
-#Copyright (C) 2006-2018 NV Access Limited, Aleksey Sadovoy, Christopher Toth, Joseph Lee, Peter Vágner, Derek Riemer, Babbage B.V., Zahari Yurukov
-#This file is covered by the GNU General Public License.
-#See the file COPYING for more details.
+# A part of NonVisual Desktop Access (NVDA)
+# Copyright (C) 2006-2019 NV Access Limited, Aleksey Sadovoy, Christopher Toth, Joseph Lee, Peter Vágner,
+# Derek Riemer, Babbage B.V., Zahari Yurukov, Łukasz Golonka
+# This file is covered by the GNU General Public License.
+# See the file COPYING for more details.
 
 """NVDA core"""
 
@@ -36,7 +36,6 @@ class CallCancelled(Exception):
 import globalVars
 from logHandler import log
 import addonHandler
-
 import extensionPoints
 
 # inform those who want to know that NVDA has finished starting up.
@@ -232,8 +231,6 @@ def main():
 		languageHandler.setLanguage(lang)
 	except:
 		log.warning("Could not set language to %s"%lang)
-	import versionInfo
-	log.info("NVDA version %s" % versionInfo.version)
 	log.info("Using Windows version %s" % winVersion.winVersionText)
 	log.info("Using Python version %s"%sys.version)
 	log.info("Using comtypes version %s"%comtypes.__version__)
@@ -388,7 +385,7 @@ def handlePowerStatusChange(self):
 			else:
 				#Translators: Reported when the battery is no longer plugged in, and now is not charging.
 				ui.message(_("Not charging battery. %d percent") %sps.BatteryLifePercent)
-
+	import versionInfo
 	messageWindow = MessageWindow(versionInfo.name)
 
 	# initialize wxpython localization support


Test patch: