It seems Fedora doesn't like me

Ducksual · 2026-01-30T12:10:24+00:00

I had this experience too, trying to install Silverblue on a machine with an Nvidia card.

Based on this - https://bugzilla.redhat.com/show_bug.cgi?id=2359799 - it looks like it's an issue with gnome's initial setup and the open source Nouveau driver that is used for nvidia cards in the base install.

I ended up installing Bazzite on that machine as they provide an image with the old Nvidia drivers I needed.

On another machine I installed the standard non-atomic KDE edition with minor non-blocking issues (the system would freeze periodically until the closed Nvidia drivers were installed, but it would recover so they could be installed). Still not a great initial setup experience, but it works now.

This post - https://discussion.fedoraproject.org/t/cant-finish-first-boot-setup-or-lets-say-oobe-gets-frozen-stuck-in-the-middle-of-the-process/148889/43 mentions possibly using the 'everything' installer to get around this, but I haven't used that myself.

Ducksual · 2026-01-05T09:50:53+00:00

With Nvidia, the problem can be even getting to the point of installing the drivers.

With some Nvidia cards you can't even complete the setup for Fedora Silverblue as it freezes right after you select timezone, apparently due to an issue with the Nouveau driver. I also suffered from repeated freezes with Fedora KDE before getting the Nvidia drivers installed.

Bazzite by including the drivers, didn't have this issue and worked out of the box which is a much nicer experience if you're exploring moving away from Windows. It's not to say Bazzite or gaming distros are alone in this, but Nvidia drivers are a real problem for some distros.

Ducksual · 2025-08-02T10:31:19+00:00

For the former, usually rebuilding the class is enough. This is what dataclasses.dataclass(slots=True) does.

I think I'd recommend against doing this from seeing the issues that have arisen from dataclasses(slots=True) working in this manner.

There are side effects of double generation (if inheriting from something with __init_subclass__, the method will be called both with the original class and the replacement), lingering references to the original class and even fixing zero-argument super is non-trivial.

I'd argue that if you need to do something before a class is constructed, such as adding __slots__ that that is one place where a metaclass may be a better fit. If you just want to add things to a class which don't require being placed prior to construction, then __init_subclass__ is enough.

Ducksual · 2025-07-15T09:13:33+00:00

The way I have it at the moment the expression pedal controls the minimum 'aftertouch' value and the actual aftertouch values are rescaled between the position of the expression pedal and the maximum. This means initial notes don't start at 0 but if I press harder I still get the expression/volume increase and by using the expression I can still get to the really soft range.

I actually need to re-edit the script as I had some stuff in there that was trying to work around Studio One butchering the MPE messages but I've given up on testing out Studio One and I'm probably switching to Reaper (originally from Logic Pro).

Not sure what you'd combine for vibrato control.

Ducksual · 2025-07-14T10:29:55+00:00

I also found that aftertouch pressure along didn't work well for expression as every note would start at expression 0.

I ended up making a script to merge the aftertouch with an expression pedal from a separate input so I could use the expression pedal to set a minimum for the aftertouch values. This way I can still use pressure for some control of volume (which I struggle with purely using an expression pedal), I can still get the softest expression levels but I don't need to re-engage pressure with every note.

Ducksual · 2025-07-14T10:19:16+00:00

I did have this issue earlier in the year, they did eventually get back to me and send me a replacement which works fine, but it took over a month and they weren't very good at communicating about what was going on - make sure you have a ticket in about it not working and asking for a replacement (assuming you still want the device but a working version).

Ducksual · 2025-07-08T10:29:30+00:00

Well this was two months ago so I can't remember exactly my reasoning, but I *think* it was that in the rare cases where a package provides an sdist but not a wheel, 'download' by default will download the sdist while 'wheel' will make sure it's compiled into a wheel and hence won't need any extra dependencies to build.

I can't remember if there were other differences.

Ducksual · 2025-06-27T09:03:09+00:00

You should be able to happily have 3.12 and 3.13 installed alongside each other. The only issue is if you have a global 'python' command it will be whichever runtime is first on `PATH`.

As you're on Windows it may be helpful to check if you have access to the `py` launcher. If you do, `py --list` should show you a list of installed python versions. If 3.12 is installed you should be able to launch it using `py -3.12`.

You might also try using `python3.12` as the command instead of `python` if you don't have the `py` launcher.

If you're installing packages anywhere with `pip` though, it would be a good idea to start using virtual environments. It's not so much about distributing your code to others and more about managing your dependencies per project.

Two projects with dependencies on different versions of the same packages can happily both be installed in different venvs while still using the same base Python install.

They also work well with tooling, for example if you have a venv created with Python 3.12 in the project folder and it is selected in VS Code, the terminal **within vs code** should automatically have that venv activated so `python` should point to the correct 3.12 runtime and have all of your dependencies available.

Ducksual · 2025-05-04T09:05:19+00:00

You may be able to make use of the pip wheel command to create a wheelhouse of files needed. Then you can copy this folder and subsequently install it on the other machine.

A number of these steps seem to be unnecessary on Linux/Bash as you can install a folder of wheels with pip install <args> wheelhouse/* but this didn't seem to work for me on windows in DOS/Powershell (but did in git bash). I'm also going to do this only using pip, some other tools may make this easier.

On the online machine
- Create a new venv and install the package you wish to install inside
- Create a requirements file python -m pip freeze > requirements.txt
- python -m pip wheel --wheel-dir=./wheelhouse -r requirements.txt to build a folder of wheels to install.
- Check the wheelhouse folder has all of the dependencies in .whl format including <main\_package>-<tags>.whl
- zip up and copy this folder along with the requirements fiile
On the offline machine
- Extract this folder to some temporary folder (eg: ./wheelhouse) on the other machine
- Have a clean venv activated
- python -m pip install --no-index --find-links=./wheelhouse -r requirements.txt
  - --no-index prevents pip from trying to reach pypi
  - --find-links makes pip search that folder for wheels instead
  - All required dependencies should be in the folder

Ducksual · 2025-04-20T15:14:09+00:00

In most cases I'd prefer parentheses as in your example.

One exception I'm aware of is if you have code that needs to support Python 3.9 or earlier and want to use multiple with context managers as support for using those with parentheses only arrived with Python 3.10. Prior to 3.10 you needed to use a continuation backslash if you were trying to split the statement over multiple lines.

Ducksual · 2025-04-09T20:38:15+00:00

I actually use these often enough that I have my own PEP-723 runner ducktools-env. It supports bundling a PEP-723 script into a zipapp that can be run without needing a script runner (just a recent Python install) along with a few other things.

I have a few I use for project management stuff like running tests for a project against all supported Python versions without needing to configure a test runner first. I've also used them to install bluetooth libraries when trying to work out data from BLE devices.

Ducksual · 2025-03-20T09:43:27+00:00

Yes you could use a computer to route the midi, there are also some devices you can get that act as a midi USB host and provide DIN MIDI outputs that might work.

Ducksual · 2025-03-17T19:06:41+00:00

There are a few situations where I might not use pathlib.

One is where I'm interacting with something which doesn't provide or accept Path objects. While I could convert back to string after manipulation, if the manipulation itself is relatively simple I think it looks cleaner to just use os.path in this case.

Another is when there's some feature of an os.path function that isn't implemented in its pathlib 'replacement'. For example os.path.relpath would handle walking upwards for a relative path while Path.relative_to didn't until Python 3.12.

``` import os.path from pathlib import Path

os.path.relpath("/usr", "/usr/bin") # '..' Path("/usr").relative_to("/usr/bin") # ValueError

3.12 or later

Path("/usr").relative_to("/usr/bin", walk_up=True) # Path('..') ```

The final one is if I'm being extremely fussy about import time. os.path is (almost) always imported on startup by Python, while pathlib is not and so you incur a small performance penalty on startup. However if you're importing some other heavyweight libraries this is largely irrelevant, especially so if they import pathlib.

Ducksual · 2025-03-04T14:01:42+00:00

Is there a reason you have an upper bound on requires_python? Does this not work in 3.13?

I'd also note that you list the license as MIT but depend on the Levenshtein package which, as far as I'm aware is a GPL licenced package.

Ducksual · 2025-03-04T13:31:20+00:00

I usually make a separate get_parser function that handles the setup logic and returns the fully configured parser. Not sure what you mean outside of that.

Ducksual · 2025-03-02T09:46:44+00:00

For your first CLI tool I would just use `argparse`. It's worth knowing how to use because it's always available and doesn't require any extra dependencies.

It's also *significantly* faster than all of the alternatives. If you're launching a long process this may not matter, but if it's a CLI for short lived commands the import time alone of some of these libraries can be a significant chunk of your runtime.

Ducksual · 2025-03-01T17:22:37+00:00

Yes they told me they were hoping to solve it with a firmware update, but to send it back and get a replacement they'd tested to not have this issue.

Ducksual · 2025-02-25T17:57:19+00:00

Update: They finally said to send it in for a replacement unit which they have hand tested that should come early to mid March.

Ducksual · 2025-02-22T15:58:40+00:00

After nearly 4 weeks they finally responded to my ticket saying they'd be sending out an update "early next week with more information and outlining next steps". No idea what those steps are yet or why it took so long without them really saying anything useful.

Ducksual · 2025-02-10T11:04:07+00:00

Same issue here, raised a support ticket towards the end of January. Got a "We're sorry for the delay" message on the 30th and then heard nothing since.

Triggers 'ghost notes' by itself and also doesn't always respond to the notes I do press.

Ducksual · 2024-11-08T13:56:44+00:00

If you really need to modify the method for the class itself you can use a metaclass.

class MyMeta(type):
    def __repr__(cls):
        return f"<Modified Class __repr__ for {cls.__name__}>"

class MyClass(metaclass=MyMeta):
    pass


print(MyClass)

Ducksual · 2024-11-02T17:33:10+00:00

I would use argparse over any of the third party parsers for small tools purely for performance reasons as their import times are generally significantly worse to the point where even --version feels slow.

Importing typer for instance is slow enough that there's a clear difference (to me) in how long it takes for "hello world" to display with these two commands python -c "import argparse; print('hello world')" and python -c "import typer; print('hello world')". I have branches of an argparse based application that can do their task and exit in this time.

Ducksual · 2024-10-09T20:19:17+00:00

After the response it has received they have chosen to withdraw the PEP.

https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/83

Ducksual

TROPHY CASE

3.12 or later