koaning.io

I was thinking about SQLAlchemy and how it has specific features for different backends. PostgresSQL has JSON support, for example, but Sqlite doesn't. So how might you make sure that your SQLAlchemy code only uses models that can be used across different backends?

Although it's probably not perfect, I did learn about banned imports via ruff. You can do something like this:

# pyproject.toml
[tool.ruff]
select = ["F", "E", "W", "TID"]  # TID enables banned imports

[tool.ruff.lint.flake8-tidy-imports]
banned-module-level-imports = [
    "sqlalchemy.dialects.postgresql",
    "sqlalchemy.dialects.mysql", 
    "sqlalchemy.dialects.oracle",
    "sqlalchemy.dialects.mssql",
    "sqlalchemy.dialects.sqlite",
]

# Or ban the entire dialects module
[tool.ruff.lint.flake8-tidy-imports.banned-api]
"sqlalchemy.dialects".msg = "Use only portable SQLAlchemy types, not dialect-specific ones"

This way, ruff will complain every time that you import from the dialects submodule of sqlalchemy.

I saw a repo the other day that had these files in it.

requirements.txt
requirements-in.txt
dev-requirements.txt
dev-requirements-in.txt

It threw me off.

Why this is bad

To be clear: requirements-in.txt is great! It's a great feature from uv pip compile and folks should feel free to use it. That's not an issue, but dev-requirements-in.txt, just like dev-requirements.txt ... different story.

Why? Let's consider what it looks like in a project. It might look something like this:

...
dev-requirements.txt
dev-requirements-in.txt
Makefile 
main.py
pyproject.tomlREADME.md
requirements.txt
requirements-in.txtd
...

See the issue? By calling it dev-requirements.txt you now create a visual separation between requirement files that should be together. Requirements for development are still requirements that need to be installed, so why store those so far away from the rest?

Sure, it's "a detail", and calling it differently won't change the behavior of any of the uv pip install -r ... commands. But it just looks wrong and it also has actual consequences. Somebody might see requirements.txt and not spot that there's a dev-requirement.txt around as well!

It's like having two half-full fruit baskets in the kitchen. One on the table and one on top of the fridge. It's just not normal.

This is better

We should keep things together when they should be, so let's rename them like this:

requirements.txt
requirements-in.txt
requirements-dev.txt
requirements-dev-in.txt

It won't add features but it will make the codebase better.

This episode of the REWORK podcast had a particular quote that deserved a bookmark.

The quote

Marketing is simply the transfer of enthousiasm.

It's gold on a lot of levels. Not only does it perfectly describes the rare sight of a developer advocate doing their work well but it also perfectly describes my frustration with a lot of tech influencers.

You can smell it when you're looking at feigned enthusiasm. It's when a product is promoted, but not celebrated. It's when you see somebody telling you to that something is great but cannot take the effort of showing you in their video. It's when you see a list of features, but not a community of people around the thing.

Real enthousiasm is the name of the game here.