logging_strict

Will commonly see examples of SQLAlchemy or SQLModel Bases that look like:

class DB1Base(SQLModel, registry=registry()):

There are x10^256 examples of this. And so lets take a step backwards and appreciate the prolific nature of

the guy in charge of random database object names

sqlalchemy docs screams to apply a database object naming convention.

alembic docs has a whole section dedicated it.

So what about SQLModel docs or issues? .... (crickets)

Every example ever lacks applying naming convention to the registry metadata!

from sqlalchemy import MetaData
from sqlalchemy.orm import registry

# copy+paste from the sqlalchemy docs. One case don't wanna be creative.
naming_convention_no_schema = {
    "ix": "ix_%(column_0_label)s",
    "uq": "uq_%(table_name)s_%(column_0_name)s",
    "ck": "ck_%(table_name)s_`%(constraint_name)s`",
    "fk": "fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s",
    "pk": "pk_%(table_name)s",
}

metadata = MetaData(
        naming_convention=naming_convention_no_schema,
        schema=schema,
)

reg = registry(metadata=metadata)

class DB1Base(SQLModel, registry=reg):

Why not to -- job security!

Can only imagine that folks wanting to give every single database object a name manually would do that as a form of job security. If that is the case then carry on.

For those of us who don't want to micro manage the micro manage of micro managers, would highly suggest not manually explicitly naming each and every database object. In each and every database. Not ever, but almost nearly ever.

For example, what if the guy in charge of random database object names gets a girlfriend? It could happen and what a disaster that would be. For him, for her, and for all the people who have to try to track down why a foreign key or unique constraint doesn't exist when it's clear as day in the code that it should be there.

Might have exaggerated, there is no agency of random database object names. But that won't stop the guy in charge of random database object names. Numerically, he can snap his fingers and poof, that agency will exist. Don't underestimate the power and unflinching resolve of the guy in charge of random database object names

The take away

Every single SQLModel Base ever neglects, when creating a registry, to apply database objects naming convention. This includes the SQLModel source code.

So why not submit a PR? SQLModel seems to be unmaintained. There are 69 PRs in the pipeline. So the options are:

• wait for hell to start selling ice cream

• poke fun at it

Only have enough coin for the boat man. So that leaves ...

Python static typing Ludwick hunger games

Market research

This post is only about dependency management, not package management, not build backends.

You know about these:

• uv

• poetry

• pipenv

You are probably not familiar with:

• pip-compile-multi

  (toposort, pip-tools)

You are defintely unfamiliar with:

• wreck

  (pip-tools, pip-requirements-parser)

pip-compile-multi creates lock files. Has no concept of unlock files.

wreck produces both lock and unlock files. venv aware.

Both sync dependencies across requirement files

Both act only upon requirements files, not venv(s)

Up to speed with wreck

You are familiar with .in and .txt requirements files.

.txt is split out into .lock and .unlock. The later is for packages which are not apps.

Create .in files that are interlinked with -r and -c. No editable builds. No urls.

(If this is a deal breaker feel free to submit a PR)

pins files

pins-*.in are for common constraints. The huge advantage here is to document why?

Without the documentation even the devs has no idea whether or not the constraint is still required.

pins-*.in file are split up to tackle one issue. The beauty is the issue must be documented with enough details to bring yourself up to speed.

Explain the origin of the issue in terms a 6 year old can understand.

Configuration

python -m pip install wreck

This is logging-strict pyproject.toml

[tool.wreck]
create_pins_unlock = false

[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
    'requirements/dev',
    'requirements/kit',
    'requirements/pip',
    'requirements/pip-tools',
    'requirements/prod',
    'requirements/manage',
    'requirements/mypy',
    'requirements/tox',
]

[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
    'docs/requirements',
]

dynamic = [
    "optional-dependencies",
    "dependencies",
    "version",
]

[tool.setuptools.dynamic]
dependencies = { file = ["requirements/prod.unlock"] }
optional-dependencies.pip = { file = ["requirements/pip.lock"] }
optional-dependencies.pip_tools = { file = ["requirements/pip-tools.lock"] }
optional-dependencies.dev = { file = ["requirements/dev.lock"] }
optional-dependencies.manage = { file = ["requirements/manage.lock"] }
optional-dependencies.docs = { file = ["docs/requirements.lock"] }
version = {attr = "logging_strict._version.__version__"}

Look how short and simple that is.

The only thing you have to unlearn is being so timid.

More venvs. More constraints and requirements complexity.

Do it

mkdir -p .venv || :;
pyenv version > .venv/python-version
python -m venv .venv

mkdir -p .doc || :;
echo "3.10.14" > .doc/python-version
cd .doc && python -m venv .venv; cd - &>/dev/null

. .venv/bin/activate
# python -m pip install wreck
reqs fix --venv-relpath='.venv'

There will be no avoidable resolution conflicts.

Preferable to do this within tox-reqs.ini

Details

TOML file format expects paths to be single quoted. The paths are relative without the last file suffix.

If pyproject.toml not in the cwd, --path='path to pyproject.toml'

create_pins_unlock = false tells wreck to not produce .unlock files for pins-*.in files.

DANGER

This is not for a faint of heart. If you can avoid it. This is for the folks who often say, Oh really, hold my beer!

For pins that span venv, add the file suffix .shared

e.g. pins-typing.shared.in

wreck deals with one venv at a time. Files that span venv have to be dealt with manually and carefully.

Issues

1. no support for editable builds

2. no url support

3. no hashs

4. your eyes will tire and brains will splatter on the wall, from all the eye rolling after sifting thru endless posts on uv and poetry and none about pip-compile-multi or wreck

5. Some folks love having all dependency managed within pyproject.toml These folks are deranged and its impossible to convince them otherwise. pyproject.toml is a config file, not a database. It should be read only.

6. a docs link on pypi.org is 404. Luckily there are two docs links. Should really just fix that, but it's left like that to see if anyone notices. No one did.

Finally got around to creating a gh profile page

The design is to give activity insights on:

• what Issues/PRs working on

• future issues/PRs

• for fun, show off package mascots

All out of ideas. Any suggestions? How did you improve your github profile?

From helping other projects have run across a fundamental issue which web searches have not given appropriate answers.

What should go in a tarball and what should not?

Is it only the build files, python code, and package data and nothing else?

Should it include tests/ folder?

Should it include development and configuration files?

Have seven published packages which include almost all the files and folders. Including:

.gitignore,

.gitattributes,

.github folder tree,

docs/,

tests/,

Makefile,

all config files,

all tox files,

pre-commit config file

My thinking is that the tarball should have everything needed to maintain the package, but this belief has been challenged. That the tarball is not appropriate for that.

Thoughts?

PEP 735 what is it's goal? Does it solve our dependency hell issue?

A deep dive and out comes this limitation

The mutual compatibility of Dependency Groups is not guaranteed.

-- https://peps.python.org/pep-0735/#lockfile-generation

Huh?! Why not?

mutual compatibility or go pound sand!

pip install -r requirements/dev.lock
pip install -r requirements/kit.lock -r requirements/manage.lock

The above code, purposefully, does not afford pip a fighting chance. If there are incompatibilities, it'll come out when trying randomized combinations.

Without a means to test for and guarantee mutual compatibility, end users will always find themselves in dependency hell.

Any combination of requirement files (or dependency groups), intended for the same venv, MUST always work!

What if this is scaled further, instead of one package, a chain of packages?!

In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It's non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

• editable mode (-e)

• extras (e.g. coverage[toml])

Personal preference

• always organize requirements files in folder(s)

• don't prefix requirements files with requirements-, just doing it here

• DRY principle applies; split out constraints which are shared.