self-contained-runnable-py VS psycopg2

The approach I prefer is to not mess with setuptools etc at all in the first place, and simply make a nice executable package.

e.g. https://github.com/tpapastylianou/self-contained-runnable-py...

The title should be: How to create a "Python DISTRIBUTION package".

The term "python package" means something entirely different (or at the very least is ambiguous in a pypi/distribution context).

To add to the confusion, creating a totally normal, runnable python package in a manner that makes it completely self-contained such that it can be "distributed" in a standalone manner, while still being a totally normal boring python package, is also totally possible (if not preferred, in my view).

Shameless plug: https://github.com/tpapastylianou/self-contained-runnable-py...

Shameless plug: I use my own template, which organises things as runnable projects.

https://github.com/tpapastylianou/self-contained-runnable-py...

It serves my purposes very well (which is creating projects that represent standalone experiments).

Sharing in case someone else here finds it useful.

More recently I've modified this a bit to also generate nice html reports straight from the __main__.py file, independently of the underlying python code, and use this as lab books (where each lab book contains a single analysis and its report). I'll upload this template separately when I find the time.

You can practice both by using https://www.psycopg.org from your Python code to communicate with your database. When I wanted to practice some SQL, that's what I did (we use psycopg at work, so that's what I practiced with, making a dream journal thingy for myself that was better than just noting stuff in a notepad because I could then look up e.g. what other stuff was correlated with Y, how many times I dreamed of X, etc. etc.)

But seems like it should work with Django 3, which you have specified https://github.com/psycopg/psycopg2/issues/1293

If you're using Postgres for your SQL, look at the "copy' method of the psycopg module (see https://www.psycopg.org/articles/2020/11/15/psycopg3-copy/) . It's much faster than INSERTs in my experience (YMMV).

Back when I used Psycopg2, there was no -binary package, so you'd get libpq set up similarly to pg-native. Docs say:

> The binary package is a practical choice for development and testing but in production it is advised to use the package built from sources.

Relevant GitHub discussion: https://github.com/psycopg/psycopg2/issues/674

I dunno, this seems worse to me.

Just go to the more easily readable docs here. I’m sorry, but the linked article is terrible.

psycopg2-binary. See https://github.com/psycopg/psycopg2/issues/1286.

psycopg2-binary, PostgreSQL Database adapter for python.

... # psycopg2==2.9.3 # https://github.com/psycopg/psycopg2 ...

I sometimes do this in testing. For example, consider the library used to communicate with a Postgres database, psycopg.