It should be enough to just drop the line linux_distro_name = platform.linux_distribution()[0].lower() in cura_app.py. It does not seem that the assigned variable linux_distro_name is used anywhere.

It should be enough to just drop the line linux_distro_name = platform.linux_distribution()[0].lower() in cura_app.py. It does not seem that the assigned variable linux_distro_name is used anywhere.

True. However, I'm very hesitant to try to ship against a Python version upstream has (clearly) never tested.

It should be enough to just drop the line linux_distro_name = platform.linux_distribution()[0].lower() in cura_app.py. It does not seem that the assigned variable linux_distro_name is used anywhere.

@prusnak -- FWIW, I've gotten a report (from @leenaars) that merely patching out that variable results in an executable that starts up successfully, but doesn't correctly operate past that point.

One place where I'd appreciate feedback is on whether it's acceptable to have the change making numpy for Python 3.6 available (vs being in a gap between Python 3.4-and-older using numpy 1.16, and Python 3.8-and-newer using Numpy 1.20) inside the same commitish as the rest of the work, or whether it should be split either into its own commit, or into a completely separate PR.

One place where I'd appreciate feedback is on whether it's acceptable to have the change making numpy for Python 3.6 available (vs being in a gap between Python 3.4-and-older using numpy 1.16, and Python 3.8-and-newer using Numpy 1.20) inside the same commitish as the rest of the work, or whether it should be split either into its own commit, or into a completely separate PR.

@FRidh, it looks like you're involved in numpy derivation maintenance -- are you the right person to ask on the above?

The 3.6 package set is not tested at all and can break at anytime. As more packages remove support for 3.6 it gets even harder to keep it working, an effort you would have to put in yourself. 3.6 is considered EOL end of this year.

The 3.6 package set is not tested at all and can break at anytime. As more packages remove support for 3.6 it gets even harder to keep it working, an effort you would have to put in yourself. 3.6 is considered EOL end of this year.

Through EOY seems like a timeline on which I'm reasonably able to make that commitment. If Lulzbot hasn't managed to put out a new release of their Cura fork by the time the newest Python interpreter they support goes EOL, that would seem like an excellent time to call Cura-LE dead.

Sure, its up to you, just be aware we don't have any CI anymore for that package set. I'd strongly recommend working with upstream at migrating to a newer Python version.

Note also Python 3.6 will be removed for NixOS 21.11.

Sure, its up to you, just be aware we don't have any CI anymore for that package set. I'd strongly recommend working with upstream at migrating to a newer Python version.

Note also Python 3.6 will be removed for NixOS 21.11.

👍; I've pinged their customer support to get an official statement on upstream maintenance plans.

(It turns out they have pushed out a minor revision, but it's only updating the frontend and not the Python libraries behind it, which are where much is the breakage is).

Upstream indicated that the failure to tag a new curaBinaryData release with updated firmware was in error, and they've retroactively created a tag at the correct position; revising the version-bump part of this PR to include the previously-missing components (which will enable support for the new 1.75mm toolhead).

I marked this as stale due to inactivity. → More info

The package has been removed in #142660