[aur-general] Merge request: python2-pyside -> python-pyside

[Xyne]

Dave Reisner wrote:

>And you'd need to do all this work at a level lower than the parser
>itself to avoid subversion via aliases, functions, and scripts which
>mask the actual operation's nature...
>
>I think I've mentioned this a few times, but I think there's 2 options
>if you want better parsing on the AUR:
>
>1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date,
>I think there's been a number of issues which no one has been willing to
>address to make this a reality.

Wouldn't that need to actually build everything to access the data nested in
the package functions? That wouldn't necessarily be a bad thing as it would
require packages to check that the package builds, but in that case you may as
well just extract the data from .PKGINFO.

>2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to
>evalulate the code. This would require something very similar to the
>guts of makepkg which understands per-package overrides. The output
>would be something similar to #1, so really... interested parties should
>just work on that.

I honestly think the best approach would be to replace Bash PKGBUILDs with a
versatile metadata language that can be easily and safely parsed, e.g. JSON with
support for variables and maybe a limited set of custom macros. Build and
package functions could be moved to external scriptlets, e.g. 
'{"build" : "/path/to/build.sh", ...}'.

Yet another item on my todo list. :P



>You'd probably be interested in shellcheck:
>
>http://www.shellcheck.net/
>
>It's written in Haskell, and while it doesn't execute anything, it does
>understand a large amount of bash syntax. I found an obscure bug in it
>recently which was quickly fixed by the author (he's a denizen of #bash
>on freenode).

That is indeed interesting.