pandora egg depends on sqlite3 egg

[Moritz Heidkamp]

Unlike the postgresql adapter, the sqlite adapter of pandora seems to depend on its database client egg (i.e. sqlite3), rendering an installation of the pandora egg impossible when the sqlite3 egg is not installed.

[(none)]

Milestone 4.4.0 deleted

[Thomas Chust]

The main reason for this dependency is that being able to test the code of Pandora requires an easy to setup database backend.

I'm undecided whether it would be better to move the SQLite3 and PostgreSQL backends of Pandora out into their own eggs entirely and leave the Pandora base code without automated tests. It would make the installation somewhat more complex and tests of the base code would be moved into the backends where they don't really belong. However, it would also make the separation of the base and backend code cleaner and remove the necessity to include copies of import libraries for the database eggs, which is a somewhat questionable practice.

[Mario Domenech Goulart]

Hi Thomas

Replying to chust:

The main reason for this dependency is that being able to test the code of Pandora requires an easy to setup database backend.

You can use .meta's test-depends just like needs, but exclusively for tests.

I'm undecided whether it would be better to move the SQLite3 and PostgreSQL backends of Pandora out into their own eggs entirely and leave the Pandora base code without automated tests. It would make the installation somewhat more complex and tests of the base code would be moved into the backends where they don't really belong. However, it would also make the separation of the base and backend code cleaner and remove the necessity to include copies of import libraries for the database eggs, which is a somewhat questionable practice.

I had this problem for ​awful too. I ended up defining some database-related parameters in awful and creating database-related eggs (e.g., ​awful-sqlite3 which set those parameters. It's not an ideal solution either, but it works.

For awful it was easy because it doesn't require much of the database egg API. Basically, connection, disconnection and query procedures.

For example, awful defines the following parameters:

;; db-support parameters (set by awful-<db> eggs)
(define missing-db-msg "Database access is not enabled (see `enable-db').")
(define db-inquirer (make-parameter (lambda (query) (error '$db missing-db-msg))))
(define db-connect (make-parameter (lambda (credentials) (error 'db-connect missing-db-msg))))
(define db-disconnect (make-parameter (lambda (connection) (error 'db-disconnect missing-db-msg))))
(define sql-quoter (make-parameter (lambda args (error 'sql-quote missing-db-msg))))
(define db-make-row-obj (make-parameter (lambda (q) (error '$db-row-obj missing-db-msg))))

The database support eggs then just set the parameters to the actual procedures. If users want to use awful+postgresql, they (use awful awful-postgresql). If they want sqlite3, (use awful awful-sqlite3) and so on.

It's kind of awful, but it works. :-)

Hope it helps somehow.

[felix winkelmann]

A pointless and not-much-related side note:

We need a database abstraction / wrapper extension.

[felix winkelmann]

I suggest to remove the sqlite3/postgresql dependencies and require the user to install an appropriate DB egg before doing the same for pandora. The setup script can check whether any DB api is installed and show a message that explains the situation for the user.

[felix winkelmann]

The current development version of chicken supports (or ...)' dependencies in the .meta-file. That way installing pandora would only require one dependency. If no element of the or` dependency is available, the first one will be downloaded and installed.

[sjamaan]

It looks like this was fixed by Felix in r23603 but the ticket was never closed.

I don't know why this "needs more thought" though.

Also, pandora has no tags so it isn't available for chicken-install.