And if you come back to this script in a few years time and it pulls a newer version of numpy with an incompatible api, there is no easy way of knowing which version it was designed to be used with...
Only if you didn't run `uv lock --script` [0] and commit the lockfile. If you don't want that second file sitting next to the script, you could instead specify an `exclude-newer` timestamp, and uv won't resolve any dependency versions newer than that.
It might be cool if uv ignored dependency versions newer than the script's last modified timestamp, but this behavior would probably need to be very explicit to avoid the situation where a working script is mysteriously broken by making an innocuous change which updates its last modified timestamp, causing uv to resolve a newer, incompatible dependency version.
I really like how clear and well laid out these rules are. It covers lots of things that I have always thought about when I write instructions in README files etc, so it's very nice to see everything neatly described/reasoned in one place. Thanks for sharing!
I tried this out, and nothing happened. Then I discovered that it has to be enabled first, for example by: https://unix.stackexchange.com/a/34251/152147
Thanks for sharing, learnt something new :)
If you're looking for a general solution to that specific type of problem, then dateutils¹ is really useful. It deals with conversions, durations, matching, repeats, etc. It also has a clear and well defined date input format, and being a collection of command line tools it is easy to mangle it in to other tools.
The problem here is that new features often involve some refactoring work. Then, if you didn't opt for feature X, the company isn't going to go out of their way to make and ship and maintain a fix for the old non-refactored version, so if you want fixes, there is no way to get them without feature X... Unless they are using feature flags of course, but then no fixes/updates are exactly "safe" for the combination of features agreed to.
Why can't they just maintain stable branches with bugfixes backported to them? You don't need feature flags for this, you can literally do this with just semver. Plenty of products support some number of previous minor versions but will backport bugfixes to them, and plenty of others have LTS releases that have a longer window of bugfixes still being made without new features.
If the claim is that there's something fundamental about car software that makes this less possible than literally every other type of software in existence, the burden is on the car companies to prove it. I strongly doubt this is the case, but if it is, I'd argue that the more prudent thing is to just _not_ keep adding features, because fixing bugs for the multi-ton behemoths hurtling alongside one another at high speeds sounds more important than literally anything that they could provide to the car that people have already decided is worthy of purchasing with the current set of features.
Interesting idea. I wonder how some examples would look for teams which have a docker compose file which don't include some services - because they are mocked for tests or expected to be run separately etc. Would it still be possible to write a k8s operator to transform the docker compose file perfectly to a k8s manifest or would it be lacking key information?
Helm did something like in the earlier versions. Helm 3 got rid of it to the great cheering of many. It didn't ingest Docker Compose files, but it is the same architectural pattern.
But there is syntax highlighting - what editor and language combination are you using? I know for a fact that SQL is highlighted inside Python and PHP strings in Sublime Text 4..
In my experience, socks are pretty expensive (at least here in Lithuania) and wear out pretty fast, so for me its reasonable to spend most of the clothing budget on socks...
