Re: Bug#890523: ITP: python3-anosql -- A Python library for using SQL

On Fri, Feb 16, 2018 at 4:29 AM, Ghislain Vaillant <ghisvail@gmail.com> wrote:

Le jeudi 15 février 2018 à 10:05 -0500, Florian Grignon a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Florian Grignon <grignon.florian@gmail.com>
>
> * Package name : python3-anosql

s/python3-anosql/python-anosql

The name for the source package should use the python- prefix as in
Python the language. The python3- prefix is intended for the binary
package providing the modules for the Python 3 interpreter.

Ok, sorry about that.

> Version : 0.2.0
> Upstream Author : Honza Pokorny <me@honza.ca>
> * URL : https://github.com/honza/anosql
> * License : BSD
> Programming Lang: Python
> Description : A Python library for using SQL
>
> A Python library for using SQL.
> Inspired by the excellent Yesql library by Kris Jenkins. In my mother
> tongue, ano means yes.
>
> This Python library is becoming popular amoung the Python community
> working with PostgreSQL and SQLite. This library has currently
> (15/02/2018) 66 stars github, and is referenced in some books (like
> MasteringPostgreSQL from Dimitry Fontaine). The library is simple and
> small. It is tested on Travis CI, and has a github repository
> https://github.com/honza/anosql.
>
> I am an experienced Python web developper, and I use this library in
> small personnal project, alongside Flask and psycopg2. This is, from
> these three libraries the only one I'm packaging myself with the
> pybuild
> buildsystem. I took example on the Flask packaging system and it
> works
> like a charm out of the box.
>
> This library is a very small library that helps Python project to use
> raw SQL queries. This can be seen as a competitor of ORM. And as
> performance becomes more and more important with the size of a Python
> project, the need to use raw SQL instead of ORM becomes inevitable.
> Raw SQL queries also gives much more flexibility and features to the
> developper compared to the ORM.
>
> This library doesn't have any dependencies. It can be used alongside
> psycopg2 for PostgreSQL or sqlite for SQLite databases engine.
>
> As a full-time computer scientist, I have time to create and maintain
> it
> on my professionnal and personnal time. I will search for a sponsor
> to
> guide me through the steps of creating and maintaining a debian
> packaging.
>
> I'd like to include the package, in a second time, to the Debian
> Python
> Module Team, and include myself to the team.

Thank you for the comprehensive description and personal motivation.

You did not mention why this package needs to be packaged though (as
opposed to being installed via pip). Is it required by another package
(or upcoming update of) currently in the archive?

As far as I know, no package currently in the archive requires `anosql`.

The motivation of packaging `anosql`, from the Debian distribution perspective,

would be to give more freedom to the debian python developer when interacting

with PostgreSQL or SQLite.

When it comes to developing a python project or software, that needs to be

packaged in debian, interacting with PostgreSQL / SQLite, the libraries helping

are quite limited to ORM. python-sqlalchemy and python-django are among the

most famous one. There's 79 packages depending/suggesting python-sqlalchemy

in stretch. ORM are seen as a drawback from Postgres DBA, not letting the full

power and flexibility of SQL. I see `anosql` as a very good option for interacting

with Postgres / SQLite, having the full SQL features and flexibility.

This point is more about educating developer and giving them more freedom

during the choice of a library to interact with Postgres / SQLite.

Concerning pip: In most of the projects I've been involved to, having only one

system to install package and manage the dependencies is a big benefit.

And the only library that is not currently in the debian archive that the projects

use is anosql.

As I'm writing this answer, I notice that most of the points are subjective.

I tried to think about the need of packaging python-sqlalchemy, python-storm

or python-django, and the only answer I got is that there's couple of projects

built on top of it already that needed to be packaged for other reason maybe.

I must be missing other arguments too.

Debian has been a wonderful place for me to start programming with python,

and I hope to contribute back with my time maintaining this package.

I read carefully https://mentors.debian.net/intro-maintainers

The next step is to upload the package to my mentors.debian.net account?

Have a good day,

-- Florian G.

Cheers,
Ghis