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
As a user, the lemmy API backend is pretty fuckin fast. The default web frontend however is a slug.
Using lemmy with a third party app like voyager is super snappy.
Oh my… I’ll eat my words about python maintainability. No unit tests, no emulation tests (with emulated services), no tests with a database, no formatter, no linter, no type hints, simple pip… The result is working, but I’m a little bit concerned about the nigh complete lack of testing and though they use an ORM (SQLAlchemy), I find the raw SQL therein (even if it’s simple) concerning.
Besides that, the end result looks quite usable and it’s nice to see an alternative to lemmy.
Yeah the lack of test suites really kicks our arse sometimes. I changed it from hard-deleting to soft-deleting stuff recently, and I forgot to check whether a post actually links to an external URL when restoring a post. The first time someone restored a post without one, it decided that it now had 189 cross-posts (i.e. all the other text posts that week). Whoops!
Yep, this Python-based project has no tests but not because it’s written in Python, lol
Attempting to get something working first and possibly adding tests later? Or are there other reasons?
Pretty much.
It’s a hobby project so we work on things we find fun or interesting. To me, tests are neither of those.
This was my experience with personal projects too.
Unit tests hinder progress so much. End-to-end/integration tests are often flaky.
The thing is, I still want to test my own project, because it’s a good idea to validate whether or not your code works or not…
Rimu I love your approach to mod tools!
Sorry if I ask this but now that Lemmy has extism plugins, wouldn’t it be better if you tried to extend lemmy with your python skills rather than keeping to build from 0? Would help the fun even more I think (?)
😄 understandable. Are you open to one or more of the things I mentioned being added? Strict type checking, tests, formatter, linting?
BTW I recently added the database structure for post licenses and have PeerTube video licence information being saved into the DB when they federate to us. However there is no UI that will let people specify a license for their PieFed posts or comments. The UI needs to present a list of licenses to choose from and reading about all the different ones made my eyes glaze over.
You might like to start there as it seems to be an interest of yours!
I feel like I’m getting nerd-sniped 😄 Believe it or not, writing tests, adding type hints, adding a formatter and linting, are actually more interesting to me than UI-work 😇
I’ll see if I can make some time this week, but no guarantees!
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.
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.
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
