zeotroph (u/zeotroph)

zeotroph commented on "We're building a new static type checker for Python" twitter.com/charliermarsh... · Posted by u/shlomo_z

IshKebab · 7 months ago

I agree, Mypy is awful. Pyright is very good but also quite slow, and its Node requirement is awkward in some cases (e.g. pre-commit).

A fast Rust based type checker would be amazing!

zeotroph · 7 months ago

There is third, pytype (by google), which I found pretty good but it rarely gets mentioned. However, like the others it is slow, so I hope this one is fast and supports all the pytype features (especially being able to type-check un-annotated code).

https://github.com/google/pytype?tab=readme-ov-file#pytype--...

zeotroph commented on Mergiraf: a syntax-aware merge driver for Git mergiraf.org/... · Posted by u/p4bl0

wetneb · 10 months ago

For now, you let it reorder every child within a given node type, which felt expressive enough to me in most cases, but I agree it would be good to refine that: https://codeberg.org/mergiraf/mergiraf/issues/6

zeotroph · 10 months ago

Looking at the nice demo, I think just defaulting to asking for confirmation if there is ambiguity, instead of dazzling the user with `mergiraf solve` magic would help; there is already a `merigraf review`. Then, a confirm prompt, an option to undo the resolution completely, or just do it on a file-by-file basis (with help what command to run next).

zeotroph commented on Venvstacks: Virtual Environment Stacks for Python lmstudio.ai/blog/venvstac... · Posted by u/ingve

zeotroph · 10 months ago

Ah, more complex than I thought: "venvstacks allows you to package Python applications and all their dependencies into a portable, deterministic format, without needing to include copies of these large Python frameworks in every application archive.", and in "Caveats and Limitations" (please, all projects should have one): "does NOT support combining arbitrary virtual environments with each other".

Is there a helper to merge venv1 and venv2, or create venv2 which uses venv1 dependencies and on load both are merged?

zeotroph commented on Venvstacks: Virtual Environment Stacks for Python lmstudio.ai/blog/venvstac... · Posted by u/ingve

incognito124 · 10 months ago

So, Docker container image, without OverlayFS benefits?

zeotroph · 10 months ago

And with just 3 layers: Runtime, Framework, Application. But at least you are not switching tools, and it presumably would prevent you from installing LARGE_v1.1, and then installing TINY_v2.2 in a later layer, which however upgrades LARGE to v1.2 and your docker images are now twice the size.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

lolc · a year ago

All this rebasing sounds like constant pain to pull from Gerrit. Does it actually create new branches v2 v3 after a rebase? Or how do I switch my local checkout to the rebased branch from remote?

zeotroph · a year ago

That's just a `git pull --rebase` away (or set pull to never merge but rebase), and all the non-merged commits are rebased onto the new upstream, and while doing the rebase the already-merged commit is dropped. The next git push origin HEAD:refs/for/main will then push the remaining commits.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

globular-toast · a year ago

GitLab supports this. Every time someone pushes or force pushes it tags that as a version which you can diff. If your developers know how to generate new commits then you can do it right away with GitLab.

The problem is generating the new commits. Developers just aren't very good at doing this. They can modify a single commit just fine, but modify a commit that isn't the latest commit involves a rebase.

Magit has the "instant fixup" option which is basically like amending an arbitrary commit instead of just the latest. What is actually doing is doing a commit with `--fixup` then `rebase --autosquash`. This technique can be used manually. Fixup/squash commits should be part of all developers' toolkits.

zeotroph · a year ago

> Developers just aren't very good at doing this.

GitHub provided a way to contribute, but also to avoid learning to rebase, thus making it more welcoming to devs who only know about commit and pull - that is what made it so popular. The squash then rebase or merge step is done on server side. Plus it has a very "harmless" UI, but that hides a lot of details (patchsets) and the layout wastes so much space imo.

This also means devs could avoid learning more about git, and this lowest common denominator git workflow makes it so frustrating for those of us who learned git all the way. I can't even mark a PR as "do not squash" to prevent it being merged in the default way which throws out all history.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

snatchpiesinger · a year ago

Another way to look at this that this is 3 linearly dependent PRs masquerading as one. Make each a distinct PR and the problem goes away, especially if you can mark the PR to depend on another one (on Gitlab you can, not sure about Github). If you want to see each change as a single logical unit, then they will each be a distinct merge commit on your master branch, use `git log --first-parent-only master` to only see these kind of changes.

zeotroph · a year ago

> [GitLab] you can mark the PR to depend on another

How much user interaction does that require, and how is this visualized in the review UI? Gerrit creates this dependency with a single `git push`.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

aseipp · a year ago

I keep saying this over and over but, Gerrit basically does that. :) You can see the relationships between any two patches on Gerrit, and more importantly, Gerrit shows you each patch individually. So you can see in a series A -> B -> C that yeah, B is small, let's go ahead and get that in.

Part of this is that UX has some really smart ideas like the "Attention Set". The attention set is basically "Which people need to take the next step?" Like a turn-based game. So, if you just did a review, you're not in the attention set for that patch anymore -- the author is.

That means Gerrit puts it down at the bottom of your queue in the UX. And what's at the top of the queue? Things where you are in the attention set! So it naturally groups things this way.

I didn't get into all the other really annoying papercuts with GitHub's UX, but even the pull request listing is worse than the alternatives. How do you know what state anything is in? You don't, you have to go read the whole thing.

zeotroph · a year ago

Attention Set <3 - that alone is worth another post. Gerrit really is one of the best kept dev secrets, and if you never had the luck of seeing it in person at a company where you worked at, well...

Makes me wonder what other git or dev-in-general blindspots I have.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

jeffbee · a year ago

For me, GitHub PR review drives me crazy. It's good for exactly one round of exchange. After that nobody can tell what the heck is going on. So my self-reported mental health would be worse.

But on non-subjective metrics it seems like LLVM PRs on GitHub are gathering noticeably less discussion than they used to enjoy as Phabricator diffs.

zeotroph · a year ago

And just visually, GitHub wastes so much vertical space, so even trying to place what belong to which patchset becomes hard.

zeotroph commented on Some of us like "interdiff" code review gist.github.com/thoughtpo... · Posted by u/todsacerdoti

zdw · a year ago

I've generally found that code review first, and rebase-centric systems like Gerrit tend to be much easier to review code in. One of the best parts of this is native support for stacking multiple patches, so people make smaller patches that are easier to review.

Code review in Github feels like a bad afterthought - the space-wasting interface that looks more like a forum thread, the inability to track over rebases, etc.

zeotroph · a year ago

There is one thing I miss on Gerrit when you push a stack of commits: A central place to talk about the whole of the stack, not just individual commits. This "big picture", but still technical stuff, too often happens in the issue tracker. But where to place it, I have no idea. This stack is just too ephemeral and and can be completely different on the next push.