A package’s requirements are left unlocked An app’s requirements are locked

This doesn’t excuse app devs from excluding a requirements.in file

Betteridge’s law of headlines

nice catch and thanks for the teaching moment

To keep it simple

testing and static type checking – catches all the bugs

linting and formatters – so git diff isn’t pure noise showing trailing and unnecessary whitespace and collaborators won’t have to go back to correct things that coulda been automagically fixed.

in code documentation – Can be extracted by Sphinx as part of the documentation process. Hint: interrogate is your friend.

gh workflows – to have the test suite run against various py versions, os, and maybe architectures. Without which not even confident it runs well on your own machine let alone anywhere else.

requirements.txt – is an output file. Where is requirements.in ??

xz hacker sends his love

Makefile – for people who like a ton of shell scripts in their Python packages. Up until realize that ya know which Python interpreter is being run, but can’t have any level of confidence about the shell interpreter. Cuz it’s a big unknown and unknowable. Gotta just take it on faith.

Admit it, the author brought a smile to your face!

Can’t stop laughing, the codebase and authors stance on packaging are hilarious.

After reviewing the source code, was gonna write helpful feedback. Then realized this project is perfect as-is.

A perfect example of what a python project looks like by those who really really hate packaging and UX.

Once upon a time, I was that guy too

Rally to protect the acolytes from those demanding efforts towards packaging and common practices!

Hey it works on their machine and maybe will on yours

Unless you use Void (sv) or Alpine Linux (openrc). Those people suck the fun out of the room.

Everyone should be using systemd, expect Grandma. She gets a smartphone.

Just activate the venv and then put it out of your mind. Can activate it with either a relative or absolute path. Doesn’t matter which

The multiple venv for different Python versions sounds exactly like what tox does

Then setup a github action that does nightly builds. Which will catch issues caused by changes that only tested against one python version or on one platform

py313 is a good version to test against cuz there were many modules removed or depreciated or APIs changed

good luck. Hope some of my advice is helpful

CPU

pep744

GPU – NVidia

numba

LPython will be obsoleted by Mojo

BFF 1: Chuck is going to be so surprised. We’ve hired the best caterers, cosplay theme, fireworks, yard ales, twister themed blind laser tag, there will be balloons, ball pool, athletic challenge course, fabulous entertainment from top notch talent, show girls, the wine will flow like water

BFF 2: Tell me you didn’t invite that grifter, mypy

BFF 1: I … err … hum. Opps

mypy enters the conversation

Don’t use lambda use def function instead

BFF 2: Man i hate that guy. Rains on our parade and sucks the fun out of the room (and this entire thread).

Heard that only pyright, not mypy, has support for the new typing syntax

Wouldn’t hurt to try out another static type checker. And if pyright is better. Switch.

Using mypy btw. Haven’t moved on to support the new typing syntax