Fixing AUR comments scrapping

[hochata]

The original version was based on a regular expression which is no longer valid.

This version uses the std/htmlparser and std/xmltree modules to find the comments.

Some additional details:

• Moved the comment formatting procedure to a top level scope
• Replaced usage of custom List with with seq
• Adding word wrapping for comment contents (by using std/wordwrap and std/terminal

[hochata]

I have some time this weekend, so if you prefer to keep using regular expressions, I could take a look.

[hochata]

A little bit off-topic, but is there a way to build Pakku without using the pakku-git AUR package? Having to modify pakku-git/src/pakku and then copy all the changes to my local repo is a little bit annoying

I tried to take a look at the Makefile and the PKGBUILD, but they are beyond my understanding.

[zqqw]

Thank you for this. Is there a reason you wrote the imports in a different style? Perhaps I might modify that later, but perhaps not if you explained your method was better! I generally try to just follow what is already there, same with the build system, that is the work of kitsunyan, but it hasn't given me any trouble, also meaning I've never needed to study it in depth. Check "man PKGBUILD" and the relevant pages on the Arch Wiki. A PKGBUILD is essentially a BASH script with some predefined variables and functions. Make / Gnu autotools are documented online too - personally I think Scons is easier and more concise although it isn't used a lot. I spent months studying both and understand neither. (Not helped by the wrong / outdated / incomplete docs.) :) I use commands like makepkg -ef, git diff >../some.patch, git apply ../some.patch, git clone, git diff --cached, cp -a, mv, that sort of thing, so just "make" up something that works for you and "git" along as best you can! I clone a fresh copy then apply a patch before committing and pushing for example but work in another dir and rebuild with makepkg -ef, perhaps running a script to delete build products and src/nimcache if required, don't know, seems easy enough. A lot of bigger projects you can't build without the build system, not properly anyway, so you get used to them, and on my hw this doesn't take long to build. It will build with just "make" too if you have the deps installed. But I do use multiple terminal tabs and nano to write and build code (which may not be normal or even a good idea), perhaps you use some IDE instead? Probably you could still integrate commands like makepkg -ef though.

[hochata]

For the imports, standard library modules can all be accessed using the std/module name. It seems that new modules (like std/wordwrap) are only accessible through this syntax, but older modules are still usable using just module. I just changed all the imports so they look the same.

I was under the impression that using just module would be deprecated eventually, but it seems that there are no plans currently. So feel free to change the rest of the imports to the older syntax.

• explanation of the std/module on the Nim manual
• forum discussion where they say the older style won't be deprecated

[hochata]

I think the build system using Makefile is fine. I just thought it was weird that you couldn't build Pakku using only the files on the repo (would it be possible to include the PKGBUILD in the repo?) and that in order to build it, it must replace the global Pakku installation instead of just creating a binary.

You can actually compile it using just Make, but I think PKGBUILD defines some env vars that are required during the compilation for the program to be usable.

And I just use Vim, with another terminal to compile everything. So I probably will just put everything in a bash file and call it a day for now.

Regardless, thanks for the links! I will read up when I have time, and see what I can improve it.

[zqqw]

As it's a BASH script you can ask it to tell you:

--- originalPKGBUILD    2022-02-19 02:15:39.518760908 +0000
+++ PKGBUILD    2022-02-19 02:21:53.791524873 +0000
@@ -27,10 +27,13 @@

 build() {
   local addargs=()
+  printf '%s\n' "${options[@]}"
+  echo "or to put it another way, options = ${options[@]}"
   grep -Fxq debug <<< "`printf '%s\n' "${options[@]}"`" &&
   addargs=(NIM_TARGET='debug' NIM_OPTIMIZE='none')

   cd ${pkgname%-git}
+  echo "make command = make "${addargs[@]}" NIM_CACHE_DIR='../nimcache' PREFIX='/usr'"
   make "${addargs[@]}" NIM_CACHE_DIR='../nimcache' PREFIX='/usr'
 }

gives:
==> Starting build()...

or to put it another way, options = 
make command = make  NIM_CACHE_DIR='../nimcache' PREFIX='/usr'
make: Nothing to be done for 'all'.

debug would be defined in /etc/makepkg.conf but that would depend on the user preference. I suppose you could make ../nimcache and /usr defaults or something. But if you build it then how do you install it on your system to test it? If it's a package you can just do pakku -U. And if you don't install something as a package then it ought to go in /usr/local, which it does:

$ ag PREFIX
Makefile
36:PREFIX = /usr/local
38:BINDIR = ${PREFIX}/bin
39:PKGLIBDIR = ${PREFIX}/lib/pakku
40:BASHCOMPLETIONSDIR = ${PREFIX}/share/bash-completion/completions
41:ZSHCOMPLETIONSDIR = ${PREFIX}/share/zsh/site-functions
42:MANDIR = ${PREFIX}/share/man

and I'm not sure defining nimcache as being in the current or parent dir is going to make much difference to how it works:

$ ag NIM_CACHE_DIR
Makefile
55:NIM_CACHE_DIR = nimcache
115:    --nimcache:"${NIM_CACHE_DIR}/tools" \
121:    --nimcache:"${NIM_CACHE_DIR}/main" \

Unlike most AUR packages, pakku is entirely useless without the AUR, pacman and makepkg so it doesn't really matter I think, kitsunyan (who clearly had a huge depth of understanding of all the elements) simply stuck things together in the easiest way possible, and was quite happy to use makepkg, and a lot of packages require you to define things like that at build time anyway. I've seen some AUR package maintainers keep a copy of the PKGBUILD in their own GitHub repo as well as on the AUR, but I can't recall seeing packages themselves including them in their repo.

[zqqw]

Actually it works fine here if you simply git clone the repo, and then:

$ pakku -R pakku-git
$ make
# make install

(But be careful as it will overwrite /etc/pakku.conf as there is no makepkg to make a backup file if you didn't remove your regular pakku first, and other than that caveat it is possible to have the two installed together it appears.)

[hochata]

Well, this is embarrassing...

I spent some more time looking at the Makefile and reading a little bit of bash documentation, and it turns out you can just call make src/pakku and a fully functional Pakku executable will be compiled at src/pakku, no PKGBUILD needed.

In the same manner, you can build the documentation using make doc/pakku.8 and make doc/pakku.conf.5 and the completions with make completion/zsh and make completion/bash.

This is exactly what I was looking for. I guess I'll document this things in the Wiki. Thanks for the help!

[hochata]

Could you enable Wiki editing?

[zqqw]

You should get a collaborator invitation, to edit the wiki you also get permissions to make commits and so on: "Only once every hundred years can a Firebender experience this kind of power" https://www.youtube.com/watch?v=eJiA3X0fZfk (About 3m50s in, Master Pakku was a character from there if you hadn't spotted that before, use your powers wisely!)

I think if you dig down far enough you could build it with nim c commands too. A feature of make (and other build tools) is incremental builds, if you build, then edit one file, it will only rebuild what it needs to and link to the existing stuff, so there isn't a huge advantage in worrying about building only parts manually, as it will do that anyway. But do whatever works for you, of course.

[hochata]

Lol, cool quote hahahaha

Thanks for the invitation! And sure, you could compile it just with nim if you define the env vars manually. But I agree that using make is more convenient, specially the incremental build.

But sometimes it is useful to build just a part of the system. For example, I just realized that the newest Asciidoc in the Arch repos is broken. So using make to build Pakku fails. But using just make src/pakku still works fine without having to rollback the Asciidoc version.

The other thing I didn't like about using the whole PKGBUILD tool chain is that it replaced your current Pakku installation. But by using make src/pakku you just get a binary. I think that it can be useful for experimentation.

But yeah, in the end whatever fits someone isn't that relevant, as long as the project tool chain works fine. I am just glad that what I looking for didn't require modifying anything :smiley_cat: