- cross-posted to:
- opensource@programming.dev
- cross-posted to:
- opensource@programming.dev
Welcome to a new era of interconnected content discussion with PieFed – a link aggregator, a forum, a hub of social interaction and information, built for the fediverse. Our focus is on individual control, safety, and decentralised power.
Like other platforms in the fediverse, we are a self-governed space for social link aggregation and conversation. We operate without the influence of corporate entities – ensuring that your experience is free of advertisements, invasive tracking, or secret algorithms. On our platform, content is grouped into communities, allowing you to engage with topics of interest and disregard the irrelevant ones. We utilise a voting system to highlight the best content.
Video introduction the codebase
Yes we could really do with all of those. Patches welcome. Other than a preference for PEP 8 I don’t have strong opinions about particular linters or formatters.
I see the benefits of types but am not puritanical about it. I’m ok with the way we’re using types at the moment. Most utility functions have types specified, especially those that return database objects so the type information flows up to the routes pretty well. I mostly see it as a way to help my IDE autocomplete work better than as a holy grail. I’m sure there are places where more types could be added but making it a policy that every function must have a type signature seems OTT.
To keep it simple
testing and static type checking – catches all the bugs
linting and formatters – so
git diffisn’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.