Ludovic Courtès writes: > Pjotr Prins skribis: > >> Patch b24765139c8940541b23f84592d3580d53f71d71 >> >> (define-public sqlite >> (package >> (name "sqlite") >> - (version "3.8.11.1") >> + (version "3.10.0") >> (source (origin >> >> is the cause of python(2|3)-sqlalchemy breaking. I confirmed that by >> regressing to the original sqlite package. Since the python binding is >> part of the interpreter, I suspect there may be more python modules >> vulnerable. I updated python-sqlalchemy to latest and that makes no >> difference. Its tests fail on sqlite 3.10.0 and pass on 3.8.11.1. >> >> What do we do? Revert on this sqlite patch for the new guix release? >> Or add a second sqlite package and have that as a python dependency? > > I would do the latter, assuming that soon a new python-sqlalchemy > release would solve the problem. WDYT? > > This is probably OK since python-sqlalchemy is a leaf, and so we’re > unlikely to end up mixing two different SQLite versions. > > Ludo’. Will sqlalchemy really remain a leaf node? I hope not, since I'm working on packaging MediaGoblin now :) Regardless, I agree that the second approach seems to be the right one. I've built a modified package, sqlite-legacy-for-python, and put it to use. I built it and confirmed it builds fine and that the tests pass, and with it, the tests pass in python-sqlalchemy too. Ok to push?