I had never really considered partying as a reality-shifting tool, but as someone fond of regional burn events, yeah, it totally is.
Humans have partied for aeons. It's not just about letting off steam, it's about building social bonds, it's about traditions and rituals and marking key points in life.
This whole thread makes me rather sad, but in the same breath, makes me feel like there is real, actionable good to be done by promoting and helping run events. Not corporate pay-to-play curated experiences, which keep you on rails and only serve to condition more consumption behaviors, but relatively low cost, volunteer-run, do-it-yourself events. The latter, from my experience, have an absolutely infectious component of wanting to contribute, volunteer, create art, and drag others into the experience. But they are also a lot of work and not everyone is cut out for it.
It really has me thinking about lowering the bar to any sort of experience that gives folks a reprieve from the default world, however fleeting.
> - else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run
That's not even correct. Not all projects with pyproject.toml use poetry (but poetry will handle everything with a pyproject.toml)
Just try uv first. `uv pip install .` should work in a large majority of cases.
pipenv is on the way out. bare `setup.py` is on the way out. `pyproject.toml` is the present and future, and the nice thing about it is it is self-describing in the tooling used to package.
I wish setup.py was actually on the way out, but sadly, it's the only straightforward way to handle packages that use cython or interop. In these cases, libraries use setup.py to compile the dll/so/dylib at install time. Naturally this is a bit of nightmare fuel since installing gets arbitrary code execution privileges but there's no real standard for privileges in python package installs.
Pants and uv are two very different tools, with very different use-cases.
uv is basically souped-up pip.
Pants is an entire build/tooling system, analogous to something like Bazel. It can handle multiple dependency trees, multiple types of source code, building and packaging, even running tests.
uv is so much more than just a souped-up pip. It can also, for example, do building and packaging.
It also has workspaces and subprojects features that are sneaking toward something like the full-fledged multi-artifact project support you get in Pants (or Poetry, with plugins). Except that their decision that the entire project must have one and only one global dependency solution means that there's no escape hatch if you ever end up in a dependency hell situation. Which is fairly common in Python for a variety of reasons. And, even when it does work, subprojects all sharing a single virtualenvironment means it's really easy to accidentally create an undeclared dependency and never notice at development time because it's already in the venv due to a sister project already having declared it. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive.
That's a major reason why Python development culture decided to go with many project-specific virtualenvironments instead of a single global one like what uv is trying to drive toward. And it's true that it still allows you to do independent projects that reference each other at development time using path dependencies. But, unlike some of its more mature alternatives, it doesn't give you any help with replacing those path dependencies with named, version dependencies at build time. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive.
What for? Support legacy CI/CD pipelines or something like that?
uv.lock already contains locked versions of all dependencies plus a lot of other needed metadata.
Maybe. I've been programming in C++ and also in Python for almost 20 years. And I'm just happy that Python has finally started to have convenient tools for packaging and dependency management. I thought everything was cursed here, and I just hate requirements.txt. It seems they were able to overcome this curse.
Absolutely brilliant. It's so stupid (in that it's kind of silly how easy it is to game our mammal brain) but I can absolutely see this giving an extra kick of motivation.
Have you heard of the INCUP model for ADHD? Interest, Novelty, Challenge, Urgency, and Passion. The more factors an activity has, the more drive the ADHD mind has. Rarity system adds novelty and a bit of passion.
Also if you have looked into operant conditioning at all, you know that variable interval reward schedules are the strongest behavior-forming systems (hence, slot machines and every game that act like them).
Yes, I was familiar with the concept of INCUP, but I had never seen it summarized so simply.
As for variable interval rewards, I knew about the concept, but I did not include it in the article because it is already too long, and also because I have not yet found a smart way to use it in my productivity system.
I tried creating my own loot box reward system where I earn points for completing tasks (literally spare change), and I can use the money to buy a die roll, with a d20 dictating what prize I got. Prizes would be things like permission to buy Pokémon cards or a full price video game, etc, with a guaranteed "high rarity" prize every X rolls.
Maybe it'd be fun to combine this with your receipts, where random tasks reward points to earn prizes.
I love it. Using a thermal printer to print physical tasks you can crumple on completion and throw in a bin is absolute madlad goblin energy and I'm all for it. I think you've actually perfectly distilled the essence of "game-loop" and operant conditioning, and mapped it to the real world. I have been using a whiteboard for tasks, which is better than nothing, but the problem with that approach is the feedback is minor, and once erased, it's like "wtf did I even do this week". So there is limited short-term feedback and zero long-term feedback. You need both the power-up noise and the level progression for a loop to be satisfying.
I have been planning on making a system based on those long scrolls of paper for doodle boards, so at least there is a history, but of course I procrastinated on building the mount for it.
I would love to use your application, I know there's a million to-do apps out there but I get the overwhelm/daunting very easily, so I really appreciate the scope-hiding aspect.
One comment: You're dopamine hacking. My belief is that eventually the process will stop rewarding you with dopamine, and you'll drop it.
Games eventually stop rewarding you with dopamine, and your brain loses interest in them. Same goes for the jar. ADHD brain needs to keep changing the process, in order to keep the reward novel. What works today won't work in six weeks.
(With me it was tearing the index card in half when I'd finished the task. Very satisfying - for a while)
As a former chef who lived by tasks on paper tickets for several years, I recommend getting a tab grabber and spike, for an extra little dopamine hit. It's very satisfying to pull the receipt from the grabber and spike it
Definitely a tactily-satisfying motion. Those spikes always freaked me out- you're one slip away from a Final Destination "spike through the eyeball" situation.
Then you need central coordination, either a single central server containing the counter, or something like Snowflake where you have multiple counters, each assigned orthogonal blocks ahead of time (that need to coordinate with a central server).
UUIDs/ULIDs/etc are fully distributed, you can have two clients assign an ID without coordinating with ~0% of collision.
You could also split the u64 to have the first 24 bits be unique to the client, and the last 40 be unique to the produced character. This would still allow 1 TiB of data produced per user and session. The single mutex would be the user ID counter.
Humans have partied for aeons. It's not just about letting off steam, it's about building social bonds, it's about traditions and rituals and marking key points in life.
This whole thread makes me rather sad, but in the same breath, makes me feel like there is real, actionable good to be done by promoting and helping run events. Not corporate pay-to-play curated experiences, which keep you on rails and only serve to condition more consumption behaviors, but relatively low cost, volunteer-run, do-it-yourself events. The latter, from my experience, have an absolutely infectious component of wanting to contribute, volunteer, create art, and drag others into the experience. But they are also a lot of work and not everyone is cut out for it.
It really has me thinking about lowering the bar to any sort of experience that gives folks a reprieve from the default world, however fleeting.
reply