I read it yesterday, a few topics are not absolutely clear still...
In the past many packages used srcDir = "src" in the nimble file and put the .nim file in that src directory. Will that remain valid, or is that deprecated?
You wrote about tags -- should we tag the initial version at github already, for example with v0.0.1 ? Indeed I have that feeling, but I was not sure because in Listing 5.9 there was no tag command used.
If I create a wrapper, maybe from glib header 2.46.0: So I would use that version string, and append one more subversion for my own fixes? So 2.46.0.0 for initial release, and 2.46.0.1 for some fixes for the same C header?
I am not sure how nimble decides what is a library package, and what is an application.
For some cases we may need meta packages, for example for gtk we need cairo, pango, glib and more. Some peoole may want only cairo, because it can be used alone. But some people may want all what is related to GTK, including gtksourceview, which is not really a dependency of GTK. So I think I should consider making a GTK meta packages which pulls in all the related packages?
Finally one remark to page 172 "Nimble does not let you import any modules whose packages you have not specified as dependencies in your project’s .nimble file." I guess with "any modules" the Nim core modules like strutils are not meant?
In the past many packages used srcDir = "src" in the nimble file and put the .nim file in that src directory. Will that remain valid, or is that deprecated?
That's still valid. All the options are documented here: https://github.com/nim-lang/nimble#nimble-reference. (The chapter does link to the readme on multiple occasions, maybe it should link more often though?).
You wrote about tags -- should we tag the initial version at github already, for example with v0.0.1 ? Indeed I have that feeling, but I was not sure because in Listing 5.9 there was no tag command used.
This is mainly up to you.
If I create a wrapper, maybe from glib header 2.46.0: So I would use that version string, and append one more subversion for my own fixes? So 2.46.0.0 for initial release, and 2.46.0.1 for some fixes for the same C header?
Sure, you can do that. But I would recommend the use of semver if possible.
I am not sure how nimble decides what is a library package, and what is an application.
If you specify the bin option then it is an application. Again, the readme has more details.
For some cases we may need meta packages, for example for gtk we need cairo, pango, glib and more. Some peoole may want only cairo, because it can be used alone. But some people may want all what is related to GTK, including gtksourceview, which is not really a dependency of GTK. So I think I should consider making a GTK meta packages which pulls in all the related packages?
I think it's better if we add support for meta packages in Nimble's packages.json format. You can create an issue for that on Github if you want.
Finally one remark to page 172 "Nimble does not let you import any modules whose packages you have not specified as dependencies in your project’s .nimble file." I guess with "any modules" the Nim core modules like strutils are not meant?
Indeed. I will mention that.
As always, thank you for the feedback!