[aur-dev] [AUR2] Need some feedback

[Sebastian]

I'll cover a few things in this mail since I didn't want to spam the
ML with 3+ threads.

First off I'd like some feedback on the RPC interface. I know that AUR
started work on using JSON, and in my mind it's the best contender.
Django has inbuilt support for serialising to XML, JSON and YAML, so I
could easily use either of those. I'm mainly interested in the user
end of this - the AUR frontend (yaourt, etc.) developers. I haven't
found anything to parse JSON or XML easily from bash, so I don't think
it would be easy to implement either way in yaourt and other
frontends. There's a Perl CPAN module[1] which may be easily used to
quickly parse the data and allow the rest of the work to be done via
bash, which, I guess, would be a decent compromise.
In my opinion XML is just way too heavy and has too many unnecessary
features for what we're going to use it for. YAML seems to be about
the same, but JSON is a nice data oriented RPC that can be quickly
parsed. If all goes well and we choose JSON, the interace will be
compatible with AUR's, though I haven't looked int othe code much yet.

On the wiki[1] someone asked to have versioned dependencies. Currently
I've only implemented listing of dependencies and don't even track the
version requirements. I'm not certain that this functionality is
necessary at all. It has very little use, and the only use cases I can
think of are validation the package, so that it's compatible with the
dependencies (ie. disallowing to upload a package that depends on an
older version of a package in AUR), and simply being notified that the
versions don't match. Both of these, in my opinion, are pointless.

As with versioned dependencies, someone asked for the ability to
search for outdated packages. There are two use cases that I can think
of for this. One is for a TU to find any outdated packages in
Community in order to update them. I'm not exactly sure of the TU
etiquette, as I'm not a TU, so I don't know if TUs update other TUs
packages if they are out of date and thus this use case may not be
valid. Another use case is to simply find all the outdated packages
that you maintain. This is a bit pointless and probably not suitable
for the search page. Any maintainer will most likely be able to
quickly see any outdated packages in their Account page or by
searching for packages maintained by them (since they are marked).
Otherwise it could be implemented in the Account page, something like
a checkbox which would toggle whether to show only out dated packages.
I'm not really enthusiastic about this feature, since it is quite
pointless.

Another request was for regexp searching. This can probably be easily
implemented since Django has this functionality built in [3]. I'm not
certain that this feature would be useful. Personally I can usually
(99% of the time) find the packages I want by using simple fulltext
searches. I know that AUR frontends do regexp searches to be
"compatible", in a way, with pacman's searching abilities. This is the
only real use case I can think of. Most users of the web interface
probably won't need it, and therefor it could be implemented in the
RPC interface instead.

Now the biggest issue I have is integrating an SCM. This should
probably go in a separate thread, but I may as well discuss it here. I
don't know how AUR or the main site handle it, I'd have to look into
that, but I would really like to integrate an SCM backend for handling
files. Initially I had the idea for the interaction to go both ways; a
user could simply "git commit -a -m 'bumped version'; git push" and
the everything would be updated in the database, but also for the
ability to do it via the web interface like it works now. Dan pointed
out that it would be hard to restrict access for the maintainers to
the various repositories/modules (or however the repository would be
split). The whole idea could generally raise many problems, so it may
be better to go for an easier solution and have it only work one way,
ie. via the web interface. It appears the TUs use CVS directly to
upload packages, so they may be a but frustrated with that move.
There's also the issue of which SCM to use. It seems the main site is
leaning towards converting to SVN (and rsync) from CVS, but git is
also a contender. Optimally only portions of the repositories could be
checked out, so instead of checking out the whole repository, as it
currently is with abs, you'd be able to just have the packages that
you maintain. I don't know of any SCM that implements this well
though.
I would really love some feedback on any ways to implement this, which
SCM to use, etc. But I don't want discussions to go on for ever like
they are with the main site conversion.

Thanks for any feedback.

[1] http://search.cpan.org/~makamaka/JSON-2.02/lib/JSON.pm
[2] http://wiki.archlinux.org/index.php/AUR_2#Ideas
[3] http://www.djangoproject.com/documentation/db-api/#regex