-
I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).
Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.
If you're not using using `direnv` yet, you are doing yourself a disservice.
-
Let's say you want to do good type-checking for the #Python project you're working on. You pick a tool, maybe you use it as an #LSP also (so your editor can show you errors, too). As an example, I'm using #Ty at the moment. There's three places this might be installed: globally (e.g., `brew install ty`), as a dev-only dependency inside your project (e.g., `uv add --dev ty`), or -- and this one might surprise you -- it might only be used and installed by `pre-commit`, which builds a separate environment for each needed tool (which is great for instance where I use `codespell` as a `pre-commit` check, which seems to need some higher version of Python than my actual project).
Where should you install it?
If you're the only one on your team running it, globally is fine. If more than just you, then absolutely as a dev-only dependency inside your project ... and **maybe** globally as well.
The only real problem is updates. If you use a reasonable global install scheme, updates will be easy. They're less easy inside your project or in `pre-commit`. And you might care one way or the other! I **don't** want updates! I **do** want updates!
As for Python type-checking, `ty` seems good so far, but not enough experience with it yet. `basedpyright`, `pyrefly`, and `ruff` all good. These four are my favorites.
#BasedPyright #Pyrefly #Ruff #PreCommit #CodeSpell #Homebrew
-
Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
-
@CGM I never heard of #SASL! I have always been a huge #Wirth fan. Did tons of real-life work in #Pascal, moved through #Modula2 up to, finally, #Oberon2. Had such fond memories of it that I tried to use it last year for #AdventOfCode and learned that it was not nearly as good as I remembered. Have you tried #Racket (a kind of #Scheme)? It’s not for me but it’s interesting. Used it in a job interview once. Your description of how flow control is defined in #TCL really reminds me of Racket. I’m learning #RustLang and having the kind of #Macros you get in #Lisp and Scheme is another reason Rust is so enjoyable.
-
Well … I get symbol renaming if I use #BasedPyright as my #LSP
-
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
-
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
-
When I was a child, I thought the world had things that were true and things that were false, i.e., things were "black and white".
Things happened to me, including reading "Gödel, Escher, Bach: an Eternal Golden Braid" #Godel #GodelEscherBach, and I realized "Oh! There’s a gray area! (and not only that, the very edges of the gray area are fuzzy!"
And then I learned about #Bayes (and #Laplace) and realized: "Oh shit! It’s **all** gray!"
It feels like you **know** some things to be true because have assigned them such high probabilities. So high, they seem certain. Sorry. It’s not actually 1. And always remember: probability is what you **know**; reality is outside of that (just like "is your blue the same as my blue?"). Yes! Your model is good enough to navigate the world and make good decisions; but absolutely don’t confuse that with having no room left to learn.
I know I said this in a weird way, but keep growing.
-
There’s a strong urge to believe what you wish instead of what you can prove. Computer rumors are a great example. Many rumors have no basis other than being a feature someone wants. They call it "wish casting".
We want the world to be black and white. Some given statement is either true or false. But it’s not. Gödel #Godel describes at least three states: true, false, and unprovable (e.g., the statement "This statement is false". Can’t be true or false; it’s unprovable. Maybe there’s a better name.)
But it’s worse than that.
In science, a theory isn’t true … it’s just the best explanation we have so far. The whole endeavor of science is to keep finding better explanations. To make good decisions you don’t need the absolute best explanation, just one good enough to guide you to beneficial choices. (I said "prove" before, but to be more accurate I should be talking not about what you can prove, but about what you can’t disprove.)
#Bayes (really #Laplace) says a given notion isn’t true, it’s actually true-with-some-probability. Each new thing you observe impacts that #Probability. This is the actual math behind the #ScientificMethod. And it’s the truth of the world. Your beliefs must adapt to your observations, constantly, forever.
If you have unshakable faith in some set of "facts", you’re probably doing it wrong. Even when you’re right, you could be righter.
Of course, if you don’t adjust your beliefs with new input, if you don’t test, if you have "facts" instead of "very probable theories". If you believe things because of how strongly the person who convinced you believed instead of what they could actually show you. If you believe simply because that’s what your parents taught you. Then, well, you **might** be right (even a stopped clock is right twice a day). But at best you’re not going to make good decisions for yourself, and at worst you’re going to try to tell others what to do based on an inaccurate understanding.
It’s messy; and that’s just how it is.