This isn’t an argument against the standard way of doing things, it is an argument to follow the xdg standard, and use xdg environment variables, rather than creating a new unconfigurable directory in $HOME.

Maybe my issue here is that the whole “buildPythonPackage” ecosystem of nix is fundamentally at odds with the python ecosystem of late, and the rest of the nix ecosystem is better.

Python has been moving toward a more “define your exact dependencies” model lately (see pipenv, poetry, piptools, etc.), while nixpkgs expects that python package dependencies can be replaced with whatever version is in the nixpkgs repo (essentially the opposite view). Nix also assumes that tests will catch any problem caused by a version mismatch, which means defensive dependency pinning won’t work. (A dependency that is pinned to be under some assumed api breaking change is trying to prevent code from breaking before it does. If the dependency changes behavior in a way that changes results but still works, it will break the code in ways that tests don’t necessarily catch)

This is wrong more often than it is right. Partly because of the pain of the arm64 transition on Mac, and the Mac vs linux issue, and the fact that data science based python packages frequently have dependencies on C libraries (which just multiplies the dependency space), I have yet to have a python package build correctly the first time from nix.

But this is partly beside the point. If I have to learn a new way to install packages for every language, then I kinda have to be knowledgable in nix and the language to install a throwaway piece of software in whatever ecosystem I want to try out. I can probably make the buildPythonPackage thing work for python, because I know python… but if I have to do that for a nodejs project? or a ruby project? When I just want to use the output of the package? That is a ton of work to use a nix system… is that really the only way?

Acetone is fine.

This is actually one of my pet peeves. Acetone is far from the “universal plastic solvent” that it has as a reputation…

Ultem, aka pei actually does great with acetone: https://www.astisensor.com/ultem.pdf.

I use acetone pretty regularly on my sheets and I haven’t noticed any bad effects. Usually it is best to use soap and water, acetone and isopropyl alcohol. If things won’t stick, do all three (in that order).

I wish you could config defaults for zsh/nvim in the Nixos config. I have some servers that are generated from a config file and then meant to not be managed after that (so I build a sd card for them and insert card and they are booted into a working system. If a configuration needs to change, the idea is that I rebuild the sd card rather than rebuild on the server.)

Home manager manages dot files, which aren’t managed at the Nixos config level. Sine this means managing the version of the corespondent package related to a dotfile config, home manager has to manage packages.

So, in my world: the only thing in home manager are programs which have dot files that need to be managed… everything else is in the Nixos config level. Except for local dev environments, which have flakes associated with them.

Yea, it is losing the forest for the trees. Next should be taught as part of iterators and for loops. It makes sense there. It doesn’t really stand on its own much.

To be honest, I’m not sure why it is a built in function… I feel like saying that python calls the ‘next’ function of your class when iterating is enough. But maybe I’m missing something.

All ‘next’ does is call ‘next’, which is part of the spec for ‘iterator’s.

Iterables return iterators when ‘iter’ is called on them. So they don’t need to support ‘next’ natively, their corresponding iterator does that.

The value of cargo and go tools doesn’t come from the all-in-one nature of them, it comes from the official nature of them.

If something doesn’t work with cargo, it is a bug. Period. There isn’t any “it works with pip” back and forth arguing over whose fault it actually is (package? Or poetry/pipenv/pip-tools/conda/etc? This happened with pytorch a while ago, and I’m not sure if poetry and pytorch get along even now)

There also isn’t any debate over project files or configuration stuff — Pyproject.toml vs setup.cfg vs random dot files in the project directory — if you are a currently developed project you support whatever cargo supports and you move to support the latest format rather than dragging your feet for years (pyproject.toml has been the “next thing” for python since 2016! And is only finally getting widespread support now… 7 years later).

A Voron 0.1 with a 0.2 gantry and a Voron 2.4 with a 2.4r2 gantry (currently being upgraded to canbus and stealthburner).

They are different though, and the article doesn’t go into why they are different, which I think is a major omission (though a common one in articles about this subject).

The difference is that lambda functions are late binding, while partial functions are bound when they are created. This can lead to all sorts of hard to find bugs when using lambdas that are avoided by using partials.

I think part of the problem isn’t just bad hierarchies, it is that they are so hard to fix.

Bad OOP code gets its fingers everywhere, and tearing out a bad hierarchy can be downright impossible.

If this is a one off, you could try manually removing the lines of gcode for those traces. Though this would get tiresome if you wanted to do this a lot.