These are somewhat “longform” blog posts. For shorter code snippets, notes, tips and tricks, see cheat-sheets.
Workarounds to install and run the Intel version of sofware that will not run natively under the ARM architecture.
I recently got some feedback (thank you @simmel, much appreciated!) on a previous post on 2021-04-17-debugging-poetry. I then realized it was a bit hard to follow if all you wanted to do was to install Poetry globally, with some added control from the default installation method. This post aims to focus on this and cover the different system-wide installation alternatives that I am aware of. System-wide install with pipx You can very easily make Poetry available system-wide, by just following the installation docs....
A guide on how to set up debugging of Poetry in Visual Studio Code, using Pipx and Pyenv. Prerequisites My developer environment is Ubuntu 20.04 via WSL2 running on Windows 10, so that’s what this guide is written for. In order to get set for debugging, we need to install/setup a couple of tools: Pyenv - Python version management Pipx - install and run Python applications in isolated environments Poetry - you should know what this is, if you are reading this ;) Pyenv I like to pick the Python interpreter version for a system-wide installations of tools, but also for individual projects using Pyenv....
A simple and homegrown UUID base62 encoding/decoding implementation.
Quick notes on getting set up with remote development in Visual Studio code on Windows 10.
The new Windows Terminal (codenamed “Cascadia”) was revealed at this year’s Microsoft Build conference and quickly received a lot of attention, as it addresses the decades-old terminal experience in Windows. This is me jotting down notes on how to get up and running with the new Terminal before it gets officially released in the Windows store, using Visual Studio 2019. This is all possible thanks to the fact that Microsoft is open sourcing the new Terminal!...
In episode 196 of the (Python) Podcast.init a very commonly discussed topic among open source programmers is covered, which I wanted to share here. The big takeaway is that just because you put your code publicly visible online, it doesn’t mean that it’s “free” for anyone to use. At least not until you slap a license on top of it, and depending on what your goals are with putting the code publicly visible, you may want to choose the license carefully....
This is a short note on how to make a container access and control another container on the same host. The trick is to have the “controller” container map the host’s docker.sock into the container. On the host, query the uid and gid of the user which is executing containers: $ id fredrik uid=1026(fredrik) gid=100(users) groups=100(users),10(wheel) The Dockerfile: FROM centos:7 RUN yum update -y && yum install -y \ libtool-ltdl && \ yum clean all # use the uid, gid previously queried RUN useradd -u 1026 -g 100 fredrik # tail -f /dev/null will cause the container to just keep running without exiting ENTRYPOINT chown -R fredrik:users /var/run/docker....
Recursively replace all gizmos in Nuke script with a group. The only exception is the Cryptomatte nodes, which will be maintained as gizmos. Copy-paste the below code into the Nuke script editor and run. import uuid import nuke def is_gizmo(node): """Return True if given node is a gizmo (and not allowed gizmo type)""" allowed_gizmo_classes = ('Cryptomatte') for knob in node.knobs(): if 'gizmo' in knob and node.Class() not in allowed_gizmo_classes: return True def get_gizmo_names(): """Return the fullName attribute for all gizmos in script""" gizmos = [] all_nodes = nuke....
A recent discussion on 3DPRO sparked me to scribble down some ideas on how to somewhat painlessly distribute a Python package to be run in DCC applications such as Maya or Nuke as simply as possible. So this is an alternative to building a wheel and mucking around with virtual environments. You can make Python import your modules or packages even when zipped. Example, where b is our package and c....