March 2020 - Aur-dev - lists.archlinux.org

aurweb testing environment using Docker
by Lukas Fleischer 18 May '20

18 May '20

We are currently working on a testing environment using Docker. The idea is to have something that is super easy to set up and still mirrors our production environment as closely as possible. It should ideally allow future contributors to test their patch submissions without having to go through the hassle of manually setting up a full development environment. Shout-out to Yaron (Cc) for sending me an initial draft. One of the big design decisions is whether everything should be in a single Docker container vs. several smaller atomic containers (i.e. separate containers for the HTTP server, the database, the SSH/Git interface, ...), as often done in production environments. The first approach has the benefit of simplicity from a user's perspective and being able to easily set up the environment using just Docker. The second approach has the benefit of atomicity (simplicity from a developer's perspective) and is closer to what we would do if we would actually use Docker for our production environment. It would probably require docker-compose (or another tool) in addition to Docker to provide the same level of convenience we can achieve with the other approach using just Docker, though. Since Yaron and me have conflicting opinions, I would like to hear some more arguments and views. Thanks! Lukas

4 7

aurweb 5.0.0 released
by Lukas Fleischer 27 Mar '20

27 Mar '20

Dear aurweb contributors and users, aurweb 5.0.0 has just been released! You can now add a secondary email address that can be used to recover your account in case access to the primary email address is lost. Reset keys for an account are always sent to both the primary and the backup email address. Most other changes were internal. Shout-out to Frédéric Mangano-Tarumi for doing some amazing work on the backend! For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the aurweb bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aurweb.git/log/?id=v5.0.0 [3] https://bugs.archlinux.org/index.php?project=2

1 0

[PATCH] Add new upgrade instructions
by Lukas Fleischer 27 Mar '20

27 Mar '20

Signed-off-by: Lukas Fleischer <lfleischer(a)archlinux.org> --- upgrading/5.x.x.txt | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 upgrading/5.x.x.txt diff --git a/upgrading/5.x.x.txt b/upgrading/5.x.x.txt new file mode 100644 index 0000000..ba74e28 --- /dev/null +++ b/upgrading/5.x.x.txt @@ -0,0 +1,4 @@ +Starting from release 5.0.0, Alembic is used for managing database migrations. + +Run `alembic upgrade head` from the aurweb root directory to upgrade your +database after upgrading the source code to a new release. -- 2.26.0

1 1

TAP testing in Python
by Frédéric Mangano-Tarumi 23 Mar '20

23 Mar '20

In order to write tests in Python, we first need to make one important choice: the test framework. Our main constraint is the output format, which should be TAP to run along with the existing scripts. My favorite candidate is pycotap, which holds in a 157-line no-dependency module that we could put in our tests directory, pretty much like we did for `test/sharness.sh`. It is implemented as a producer for Python’s standard unittest module. https://el-tramo.be/pycotap/ Its main opponent is tappy, a set of tools for working with TAP. It integrates with unittest, pytest and nose. From the documentation, my impression is that it expects to be invoked with nose or pytest’s harness, which would be inconsistent with usual TAP test invocation consisting of calling scripts directly and relying on the shebang. https://tappy.readthedocs.io/en/latest/producers.html More alternatives at https://tappy.readthedocs.io/en/latest/alternatives.html Unless we plan to use pytest or nose over unittest, I suggest we use use pycotap. Except for a couple of lines, tests written with pycotap are standard unittest tests, which nose and pytest can collect results from too. If our needs evolve, we could easily upgrade to another framework.

3 4

[PATCH] Map BIGINT to INTEGER for SQLite
by Frédéric Mangano-Tarumi 22 Mar '20

22 Mar '20

--- aurweb/schema.py | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/aurweb/schema.py b/aurweb/schema.py index fde6512f..6792cf1d 100644 --- a/aurweb/schema.py +++ b/aurweb/schema.py @@ -17,6 +17,17 @@ def compile_tinyint_sqlite(type_, compiler, **kw): return 'INTEGER' +@compiles(BIGINT, 'sqlite') +def compile_bigint_sqlite(type_, compiler, **kw): + """ + For SQLite's AUTOINCREMENT to work on BIGINT columns, we need to map BIGINT + to INTEGER. Aside from that, BIGINT is the same as INTEGER for SQLite. + + See https://docs.sqlalchemy.org/en/13/dialects/sqlite.html#allowing-autoincreme… + """ + return 'INTEGER' + + metadata = MetaData() # Define the Account Types for the AUR. -- 2.25.2

2 1

[PATCH] Proof-of-concept of a dual PHP–Python stack
by Frédéric Mangano-Tarumi 15 Mar '20

15 Mar '20

Here’s a demonstration of a Python web stack running next to the current PHP stack, such that it’s invisible to the client. This approach aims at providing a way to migrate the PHP code base to Python, one endpoint after another, with as little glue as possible to have the two backends collaborate. Since they are both mounted on the web root, Python could implement, say, /packages/ and leave the rest to PHP. As soon as PHP yields it by returning 404 on this URL, Python will take over automatically. To run it, you need python-flask and nginx. Then, you need to start PHP, Flask, and nginx, in whatever order: $ cd path/to/aurweb $ AUR_CONFIG="$PWD/conf/config" php -S 127.0.0.1:8080 -t web/html $ FLASK_APP=aurweb.wsgi flask run $ nginx -p . -c conf/nginx.conf You may then open http://localhost:8081/ and http://localhost:8081/hello to check that the former URL goes to PHP and the latter to Flask. The key concept is nginx’s proxy_next_upstream feature. We set Flask as a fallback backend, and tell nginx to use the fallback only on 404 from PHP. See http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream The main limitation of this approach is that PHP and Python need to use the same gateway protocol, probably FastCGI or HTTP. A minor caveat with this system is that the body of the 404 returned by PHP is lost, though it could contain useful information like “Package X doesn’t exist”, rather than a generic “Page not found”. Luckily, all the 404 cases are handled by 404.php, so we could port its logic to Flask and preserve the current behavior. --- aurweb/wsgi.py | 15 +++++++++++++++ conf/nginx.conf | 23 +++++++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 aurweb/wsgi.py create mode 100644 conf/nginx.conf diff --git a/aurweb/wsgi.py b/aurweb/wsgi.py new file mode 100644 index 00000000..fd6b67d3 --- /dev/null +++ b/aurweb/wsgi.py @@ -0,0 +1,15 @@ +from flask import Flask, request + + +def create_app(): + app = Flask(__name__) + + @app.route('/hello', methods=['GET', 'POST']) + def hello(): + return ( + f"{request.method} {request.url}\n" + f"{request.headers}" + f"{request.get_data(as_text=True)}\n" + ), {'Content-Type': 'text/plain'} + + return app diff --git a/conf/nginx.conf b/conf/nginx.conf new file mode 100644 index 00000000..8e6e4edb --- /dev/null +++ b/conf/nginx.conf @@ -0,0 +1,23 @@ +events { +} + +daemon off; +error_log /dev/stderr info; +pid nginx.pid; + +http { + access_log /dev/stdout; + + upstream aurweb { + server [::1]:8080 max_fails=0; + server 127.0.0.1:5000 backup max_fails=0; + } + + server { + listen 8081; + location / { + proxy_pass http://aurweb; + proxy_next_upstream http_404 non_idempotent; + } + } +} -- 2.25.1

3 7

Functional HTTP testing
by Frédéric Mangano-Tarumi 15 Mar '20

15 Mar '20

Hello everyone, With the current plans of porting the PHP codebase to Python, we should consider setting up a suite of functional tests to squash most bugs introduced by the rewrite. I suggest the following testing plan, to be applied on an endpoint-by-endpoint basis: 1. Write functional HTTP tests for the existing software. 2. Port the code to Python. 3. Run the tests. This differs from the more appealing plan to test only the new code in Python using tools provided by the framework we’d use. I think testing the PHP code first will help find surprising edge cases we could accidentally change but that other parts of the system depend on. HTTP testing being a kind of language-agnostic blackbox testing, the tests would also resist any future rewrite or major refactoring without requiring maintenance. I’d now like to introduce a few solutions to implement that. Requests -------- Using Python’s Requests package with an HTML and a JSON parser should cover most cases. We would typically run POST requests to change the state then parse the HTML to validate the updated data. Any other programming language would work too. Perl offers better integration with our current test architecture, and its support for regex is quite practical for matching results. Mechanize --------- Perl has a cool WWW::Mechanize package that provides a higher-level interface to HTTP testing, offering basic support for forms and link detection. We would simulate use cases like “Click the ‘login’ link, submit the form, etc.”, ensuring the website is usable by a human user. More at https://metacpan.org/pod/WWW::Mechanize#SYNOPSIS Someone made a port of WWW::Mechanize for Python, called python-mechanize. Selenium -------- Selenium a software suite for testing web applications among other things. Its WebDriver component controls a full-fledged browser like Firefox, supporting in particular JavaScript. You can’t get more powerful than that. See https://www.selenium.dev/documentation/en/ I think it’s overkill because I believe AUR should never require JavaScript, as it should be usable without a GUI. I myself occasionally access it on a text browser. It’s also simpler for bots, including search engine’s. Conclusion ---------- I think it’s safe to start with Requests, and consider Mechanize later if need be, or even Selenium. Mechanize and Selenium kind of overlap with each other, so we should pick only one of the two, but Requests is well-known and should never be unwelcome. If it were only me, I’d pick Perl for its shell-like features and regex support that make it a great tool for writing tests in my opinion. However, not that many developers are familiar with Perl nowadays.

2 1