I tested it quickly on a 30kLOC project. zmypy seems to be faster than mypy indeed:
Without mypy cache:
$ rm -rf .mypy_cache
$ time mypy
Success: no issues found in 157 source files
mypy 20.40s user 2.33s system 108% cpu 20.886 total
With mypy cache without any changes:
$ mypy --version
mypy 1.16.0 (compiled: yes)
$ time mypy
Success: no issues found in 157 source files
mypy 0.56s user 1.84s system 628% cpu 0.381 total
mypy with a small change in a shared module
$ time mypy
Success: no issues found in 157 source files
mypy tests/ 2.32s user 2.06s system 168% cpu 2.601 total
zmypy:
$ time zmypy
Found 68 errors in 16 files (checked 157 source files)
zmypy 0.68s user 0.05s system 99% cpu 0.731 total
Without caching and parallelization (as the 99% CPU usage indicates) it comes in the range of mypy using the cache and multiple cores (628% CPU usage) without any changes in the code.
zmypy seems to find more errors but they mostly boil down to the following errors
* Call to untyped function "__setitem__" in typed context
* ... has incompatible type "MagicMock"; expected ...
Maybe __setitem__ and MagicMock are treated specially in mypy? Also there seem to be differences in handling Protocol and enum comparison.
So far I just pinned the rustc version used by requiring rustup as a build dependency. Let's see if this lets me drop it or if it is still easier in the end to build with pinned version.
> In addition, if you add "donate" button you'd see a lot of artists being showered with cash.
There are donation buttons for some artist on Spotify. I guess the artist need to enable it? ("Signum Regis" is an artist that has a Donate button for example)
This looks really nice and useful! I wonder if I could configure it to open things in vim directly? Because currently it seems to use xdg-open which then opens it in whatever application is configured.
I finally managed to build an ArchLinux kernel that supports out-of-tree modules written in Rust. If you're interested in the whole journey there are also the following posts:
> The real problem is that you can't use crates to improve incrementalism when you have a type in one logical part of the module hierarchy implement a trait from another logical part. Due to orphan rules and coherence, it is not possible to implement a foreign trait for a foreign type.
Well you can implement a trait for a type from another logical part either in the crate of the trait or the crate of the type.
What is the use-case for implementing a foreign trait for a foreign type if you have both under control?
> I wanted to separate the type, the trait and the implementation of the trait in different crates.
I usually put the traits in a separate crate, but keep concrete types and implementations for them in the same crate.
What is the use-case for splitting a type and it's implementation into separate crates? (except for cases where the trait or the type are out of your control, then one indeed needs to use the new-type escape hatch)
I use Pelican (https://getpelican.com/) for my blog, which works decently for me. It is a static site generator written in Python.
But you probably won't learn much Python by using it (or Rust when using a generator written in it) since you probably won't need to change anything in it.
The only Python code you need to write for Pelican is the configuration, which is just setting a few variables.
The build pipeline was already part of Linux 6.1. I played around with it on ArchLinux with the target to compile an out of tree hello world kernel module in Rust:
Nice to see that my blogposts about building a Linux kernel with Rust support on ArchLinux were useful for at least someone else :)
This post does a lot better job at describing the prerequisites to enable Rust in the Linux kernel, while I just referred to the AUR package I created.
According to the last comment there it should be fixed:
> I don't think this should be an issue in the current 2022.4.8 release because of the requirement to use index restricted packages for locking. Please advise if you think this is still a concern and we can revisit it.
But apparently it is still an issue (assuming the author did use a recent enough pipenv version)
From the article:
> Overall this is pipenv working exactly as it should.
I don't agree, IMO pipenv should just install from the source package and ignore the newer wheel, maybe showing a warning about the new wheel.
Edit: Just noticed that the author agrees in the end:
> I suppose the behavior I’d like to see here is that if my Pipfile.lock has hashes in it for a distribution, then even if additional distributions are available, pipenv sync should be allowed to continue to install from the distribution corresponding to the “trusted” hash.
I prefer to use https://python-poetry.org/ instead of pipenv, since it has less issues in my experience. But I wonder how it would behave in this situation.