Logging

[idleberg]

My editor (Atom) is setup to log stderr in red and everything else gray. When I generate an installer, the output looks like this:

I took a look at lines 448 and 506, but even with my limited understanding of Python I didn't find an explanation for this behaviour. Maybe you can look into this or explain why this happens.

[takluyver]

Logging usually goes to stderr because it's auxiliary to the main purpose of the program - the idea is that you can pipe stdout into a downstream process and still see debugging/progress information from stderr (or redirect it somewhere else). Then when it calls NSIS, that writes to stdout. It doesn't really matter here, as there's no machine-readable output on either channel.

[idleberg]

The reason why I'm bringing this up, is package for Atom that I'm working on. It would have been easiest, if I could simply determine whether an error occurred by looking if there's any output in stderr. The alternatives are parsing the output for keywords (e.g. “error”), which is unreliable, or ignore this altogether.

Anyway, knowing that pynsist only outputs in stderr is already of help. Thank you!

[takluyver]

Check for a non-zero exit code. That's the standard indication that an error occurred when you're running a subprocess. :-)

[Siecje]

Any output in stderr would not indicate an error. Progress messages should use stderr.

[idleberg]

makensis, which is subsequently executed by pynsist, makes this distinction, as do many (dare I say most) other commandline-applications.

Any output in stderr would not indicate an error. Progress messages should use stderr.

One might argue that it's called stderr for a reason. Also, it's true that the exit code tells me that an error occured, but it's stderr that tells me what went wrong. In my use-case, I would only pass actual error to the another application, in this case code editor.

[Siecje]

man stderr says it is

for printing diagnostic or error messages

[takluyver]

Now that I'm back at home and had a decent night's sleep, allow me to say what I should have said before: thanks for making an Atom plugin for Pynsist! And I see on your GitHub profile that you're doing one for VSCode as well. Having editor support for pynsist will be great. 😀 :atom: 🐍

I'm happy to think about how we can convey information about errors back to tools like these. For some classes of error (e.g. missing config keys), this should be fairly easy. But it's probably trickier if something goes wrong when building, because in those situations you often need some of the earlier output to make sense of what has happened, not just the exception message.

One thing that I find really valuable in intelligent editors is linting/checking of the files I'm writing. Is this something you're interested in for these plugins? I think we could probably make a command like pynsist --lint that would report problems with the config without actually copying files around, if you're interested. I don't think we can easily point to specific lines in the config, but reporting a list of problems should be easier.

Finally, I have a longer term plan to design a new config file, probably using the TOML syntax, to define this kind of application info for use by different tools. E.g. Pynsist could use it to build a Windows installer, and another tool might use it to build a single-file exe, or a Flatpak package for Linux, or a Mac .dmg file. If you're interested, I'll ping you as and when I do anything about that - it would be awesome to have tools to make creating it easy.

[idleberg]

Sorry for the late reply, it's been a busy week.

One thing that I find really valuable in intelligent editors is linting/checking of the files I'm writing. Is this something you're interested in for these plugins?

I have done similar some stuff in the past for Sublime Text and Atom. makensis doesn't have a linter feature, but I used the standard output from the compiler (which, of course, isn't ideal.)

While I abandoned Windows a long time ago, I still feel attached to the NSIS project. These days I mostly support it with graphics, the new website and building extensions for a variety of editors and syntax highlighters. I will gladly continue support pynsist as well, since it's a popular project in the NSIS eco-system.

I think we could probably make a command like pynsist --lint

I wonder what that would mean. From what I observed the process of creating an .nsi file from installer.cfgis very fast, do you think a --lint could speed it up significantly? Or what benefits do you see?

[takluyver]

I will gladly continue support pynsist as well, since it's a popular project in the NSIS eco-system.

I'm pleasantly surprised to hear that :-) . I've come to this from the Python world, and I didn't realise the NSIS community even really knew about Pynsist.

I also don't really use Windows myself, but I wanted a better way to distribute applications to Windows users. So one of the big advantages of NSIS is that I can easily build Windows installers on Linux.

I wonder what that would mean. From what I observed the process of creating an .nsi file from installer.cfg is very fast, do you think a --lint could speed it up significantly? Or what benefits do you see?

Creating the .nsi file is fast, but at the moment there's no command line API to do that without also downloading files and copying stuff around into the build directory, which may be slow (and may even not work, if it needs to download something but you're not connected to the internet). So I envisage --lint just reading and checking the config file without doing any of those operations.

Another potential improvement: it currently errors out as soon as it finds one problem with the config, so if there's more than one problem, it only tells you about one. It could report a list of all the problems with config at once.