FLOSS Project Planets

The end of Drupal 7 support is approaching (January 5, 2025), which means this system’s users need to migrate to a newer version. This article explains how to move smoothly from Drupal 7 to Drupal 11, the key steps, and what to pay attention to. I encourage you to read the article or watch the video in the “Nowoczesny Drupal” series.

Is your website the driving engine of your higher ed institution and a powerful catalyst for its goals? Is it effectively attracting prospective students, inspiring alumni, and building a vibrant community? There are always new strategies to boost your website's impact and ensure the answer is a resounding "yes"! As a team that specializes in higher education website design & development, we are passionate about sharing useful tips that can help those in this sector.

Craft Your Perfect Proposal: MidCamp 2025 Session Proposal Workshop

🚀 Ready to take your session ideas to the next level? Whether you're a seasoned speaker or a first-time presenter, the MidCamp 2025 Session Proposal Workshop is here to help you craft standout submissions.

📅 Date: December 12, 2024
🕒 Time: 3:00 PM - 4:00 PM CST
🌐 Location: Virtual via MidCamp Slack (#speakers channel)

Facilitated by Aaron Feledy

This workshop will be led by Aaron Feledy, a seasoned Drupal contributor and experienced speaker. Aaron brings years of expertise in proposal crafting and conference speaking, offering practical advice to help you refine and elevate your session submissions.

Why Attend?

Submitting a session proposal can be daunting—but it doesn't have to be! This workshop is designed to guide you through the process, from brainstorming topics to refining your submission. Our expert facilitators will share insider tips on what makes a proposal stand out to reviewers and resonate with attendees.

What You’ll Learn:

• How to choose and frame a compelling topic
• Crafting clear, concise, and engaging abstracts
• Tips for tailoring your proposal to different audiences
• Insight into the MidCamp review process

Session Submissions Now Open

Ready to submit? Session submissions for MidCamp 2025 are now open! Visit the MidCamp 2025 session submission page for guidelines and start your journey to the stage.

How to Join:

Simply join the MidCamp Slack and head over to the #speakers channel on December 12th at 3:00 PM CST. No registration required—just jump in and start collaborating!

Learn how to upgrade Drupal with Composer, ensuring seamless updates, compatibility, and enhanced security.

An Austrian petitioner succeeded in realizing what the US government failed to see: that free software is vital for the infrastructure of a free society.

An Austrian petitioner succeeded in realizing what the US government failed to see: that free software is vital for the infrastructure of a free society.

Creating software is an achievement worth celebrating. But software is never static. Bugs need to be fixed, features need to be added, and security demands regular updates. In today’s landscape, with agile methodologies dominating, robust DevOps systems are crucial for managing an evolving codebase. That’s where GitHub Actions shine, empowering Python developers to automate workflows and ensure their projects adapt seamlessly to change.

GitHub Actions for Python empowers developers to automate workflows efficiently. This enables teams to maintain software quality while adapting to constant change.

Continuous Integration and Continuous Deployment (CI/CD) systems help produce well-tested, high-quality software and streamline deployment. GitHub Actions makes CI/CD accessible to all, allowing automation and customization of workflows directly in your repository. This free service enables developers to execute their software development processes efficiently, improving productivity and code reliability.

In this tutorial, you’ll learn how to:

• Use GitHub Actions and workflows
• Automate linting, testing, and deployment of a Python project
• Secure credentials used for automation
• Automate security and dependency updates

This tutorial will use an existing codebase, Real Python Reader, as a starting point for which you’ll create a CI/CD pipeline. You can fork the Real Python Reader code on GitHub to follow along. Be sure to deselect the Copy the master branch only option when forking. Alternatively, if you prefer, you can build your own Real Python Reader using a previous tutorial.

In order to get the most out of this tutorial, you should be comfortable with pip, building Python packages, Git, and have some familiarity with YAML syntax.

Before you dig into GitHub Actions, it may be helpful to take a step back and learn about the benefits of CI/CD. This will help you understand the kinds of problems that GitHub Actions can solve.

Get Your Code: Click here to download the free sample code you’ll use to learn about CI/CD for Python With GitHub Actions.

Take the Quiz: Test your knowledge with our interactive “GitHub Actions for Python” quiz. You’ll receive a score upon completion to help you track your learning progress:

Interactive Quiz

GitHub Actions for Python

In this quiz, you'll test your understanding of GitHub Actions for Python. By working through this quiz, you'll revisit how to use GitHub Actions and workflows to automate linting, testing, and deployment of a Python project.

Unlocking the Benefits of CI/CD

Continuous Integration (CI) and Continuous Deployment (CD), commonly known as CI/CD, are essential practices in modern software development. These practices automate the integration of code changes, the execution of tests, and the deployment of applications. This helps teams and open-source contributors to deliver code changes more frequently in a reliable and structured way.

Moreover, when publishing open-source Python packages, CI/CD will ensure that all pull requests (PRs) and contributions to your package will meet the needs of the project while standardizing the code quality.

Note: To learn more about what a pull request is and how to create one, you can read GitHub’s official documentation.

More frequent deployments with smaller code changes reduce the risk of unintended breaking changes that can occur with larger, more complex releases. For example, even though developers can format all code using the same linting tools and rules, policy can automatically block PRs from being merged if the code’s tests don’t pass.

In the next section, you’ll learn how GitHub Workflows can help you implement CI/CD on a repository hosted on GitHub.

Exploring GitHub Workflows

GitHub Workflows are a powerful feature of GitHub Actions. They allow you to define custom automation workflows for your repositories. Whether you want to build, test, or deploy your code, GitHub Workflows provide a flexible and customizable solution that any project on GitHub can use for free, whether the repository is public or private.

Even though there are many CI/CD providers, GitHub Actions has become the default among open-source projects on GitHub because of its expansive ecosystem, flexibility, and low or no cost.

Anatomy of a Workflow File

Workflow files are declaratively written YAML files with a predefined structure that must be adhered to for a workflow to run successfully. Your YAML workflow files are stored and defined in a .github/workflows/ folder in your project’s root directory.

Your workflow folder can have multiple workflow files, each of which will perform a certain task. You can name these workflow files anything you’d like. However, for the sake of simplicity and readability, it’s common practice to name them after the tasks they achieve, such as test.yml.

Each file has a few elements that are required, but many, many more that are optional. The GitHub Actions documentation is thorough and well-written, so be sure to check it out after you’ve finished reading this tutorial.

There are three main parts that make up the bulk of a workflow file: triggers, jobs, and steps. You’ll cover these in the next sections.

Workflow Triggers Read the full article at https://realpython.com/github-actions-python/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Developed by Anand Toshniwal, a Python script now automates the creation of .component.yml files for Single Directory Components in Drupal. Simplifying workflows and improving accuracy, this tool supports projects like the Starshot Demo Design System, enhancing efficiency for developers.

You may have seen this toot announcing OpenStreetMap's migration to Debian on their infrastructure.

🚀 After 18 years on Ubuntu, we've upgraded the @openstreetmap servers to Debian 12 (Bookworm). 🌍 openstreetmap.org is now faster using Ruby 3.1. Onward to new mapping adventures! Thank you to the team for the smooth transition. #OpenStreetMap #Debian 🤓

We spoke with Grant Slater, the Senior Site Reliability Engineer for the OpenStreetMap Foundation. Grant shares:

Why did you choose Debian?

There is a large overlap between OpenStreetMap mappers and the Debian community. Debian also has excellent coverage of OpenStreetMap tools and utilities, which helped with the decision to switch to Debian.

The Debian package maintainers do an excellent job of maintaining their packages - e.g.: osm2pgsql, osmium-tool etc.

Part of our reason to move to Debian was to get closer to the maintainers of the packages that we depend on. Debian maintainers appear to be heavily invested in the software packages that they support and we see critical bugs get fixed.

What drove this decision to migrate?

OpenStreetMap.org is primarily run on actual physical hardware that our team manages. We attempt to squeeze as much performance from our systems as possible, with some services being particularly I/O bound. We ran into some severe I/O performance issues with kernels ~6.0 to < ~6.6 on systems with NVMe storage. This pushed us onto newer mainline kernels, which led us toward Debian. On Debian 12 we could simply install the backport kernel and the performance issues were solved.

How was the transition managed?

Thankfully we manage our server setup nearly completely with code. We also use Test Kitchen with inspec to test this infrastructure code. Tests run locally using Podman or Docker containers, but also run as part of our git code pipeline.

We added Debian as a test target platform and fixed up the infrastructure code until all the tests passed. The changes required were relatively small, simple package name or config filename changes mostly.

What was your timeline of transition?

In August 2024 we moved the www.openstreetmap.org Ruby on Rails servers across to Debian. We haven't yet finished moving everything across to Debian, but we will upgrade the rest when it makes sense. Some systems may wait until the next hardware upgrade cycle.

Our focus is to build a stable and reliable platform for OpenStreetMap mappers.

How has the transition from another Linux distribution to Debian gone?

We are still in the process of fully migrating between Linux distributions, but we can share that we recently moved our frontend servers to Debian 12 (from Ubuntu 22.04) which bumped the Ruby version from 3.0 to 3.1 which allowed us to also upgrade the version of Ruby on Rails that we use for www.openstreetmap.org.

We also changed our chef code for managing the network interfaces from using netplan (default in Ubuntu, made by Canonical) to directly using systemd-networkd to manage the network interfaces, to allow commonality between how we manage the interfaces in Ubuntu and our upcoming Debian systems. Over the years we've standardised our networking setup to use 802.3ad bonded interfaces for redundancy, with VLANs to segment traffic; this setup worked well with systemd-networkd.

We use netboot.xyz for PXE networking booting OS installers for our systems and use IPMI for the out-of-band management. We remotely re-installed a test server to Debian 12, and fixed a few minor issues missed by our chef tests. We were pleasantly surprised how smoothly the migration to Debian went.

In a few limited cases we've used Debian Backports for a few packages where we've absolutely had to have a newer feature. The Debian package maintainers are fantastic.

What definitely helped us is our code is libre/free/open-source, with most of the core OpenStreetMap software like osm2pgsql already in Debian and well packaged.

In some cases we do run pre-release or custom patches of OpenStreetMap software; with Ubuntu we used launchpad.net's Personal Package Archives (PPA) to build and host deb repositories for these custom packages. We were initially perplexed by the myriad of options in Debian (see this list - eeek!), but received some helpful guidance from a Debian contributor and we now manage our own deb repository using aptly. For the moment we're currently building deb packages locally and pushing to aptly; ideally we'd like to replace this with a git driven pipeline for building the custom packages in the future.

Thank you for taking the time to share your experience with us.

Thank you to all the awesome people who make Debian!

We are overjoyed to share this in-use case which demonstrates our commitment to stability, development, and long term support. Debian offers users, companies, and organisations the ability to plan, scope, develop, and maintain at their own pace using a rock solid stable Linux distribution with responsive developers.

Does your organisation use Debian in some capacity? We would love to hear about it and your use of 'The Universal Operating System'. Reach out to us at Press@debian.org - we would be happy to add your organisation to our 'Who's Using Debian?' page and to share your story!

About Debian

The Debian Project is an association of individuals who have made common cause to create a free operating system. This operating system that we have created is called Debian. Installers and images, such as live systems, offline installers for systems without a network connection, installers for other CPU architectures, or cloud instances, can be found at Getting Debian.

The next Kdenlive Café will be on the 3rd of December at 8 PM UTC.

Come chat with the team!

Join us at: https://meet.kde.org/b/far-twm-ebr

The post Kdenlive Café in December appeared first on Kdenlive.

With just 12 days remaining, DrupalCon Singapore 2024 is set to bring the global Drupal community together from 9 to 11 December at the PARKROYAL COLLECTION Marina Bay. This dynamic event will feature three days of inspiring sessions, hands-on training, and the inaugural Splash Awards in Asia, celebrating innovative Drupal projects. Hosted by the Drupal Asia Steering Committee and supported by the Drupal Association, the conference reflects the vibrant, collaborative nature of the Drupal ecosystem, offering attendees a unique opportunity to learn, network, and celebrate in one of Asia’s most dynamic cities.

Learn about Anna's journey. Since discovering Python and Django in 2015, Anna has been actively contributing to the Django community and taking up leadership roles within DSF and Django Girls.Learn about Anna's journey. Since discovering Python and Django in 2015, Anna has been actively contributing to the Django community and taking up leadership roles within DSF and Django Girls.

We interviewed Anna Makarudze from Zimbabwe to hear about her inspiring journey.

Since discovering Python and Django in 2015, Anna has been actively involved in the Django community. She helped organize PyCon Zimbabwe, and she has coached at Django Girls in Harare and Windhoek.

She served on the Board of Directors at Django Software Foundation for five years, and she is currently a Django Girls Foundation Trustee & Fundraising Coordinator.

During her journey in tech, Anna became aware of the lack of representation of women in tech industry, something that became more evident as she attended Django Under the Hood in 2016 where most of the attendees were white men, and only a few are women. That’s when she realized the importance of communities like Django Girls in supporting more women in the Django Community.

In this chat, Anna shared ways on how you can contribute and help support Django Girls+ Foundation.

She is currently studying her master’s degree in Blekinge Institute of Technology in Karlskrona, Sweden.

Be sure to listen to the episode to learn all about Anna’s inspiring story!

Topic discussed

• Introductions
• Her role in Django Girls+ Foundation
• Moving from Zimbabwe to Sweden, and adjusting to her new life
• Django Girls tutorials and website
• How to contribute to Django Girls website
• Discovering Python, Flask, and Django in 2015
• Attending Django Under the Hood in 2016
• Representation of women in tech
• The role of Django Girls+ in tech
• How to help and support Django Girls+
• What to expect from Django Girls+ in 2025 onwards

Links from the show

• Django Girls+: https://djangogirls.org/en/
• Blekinge Institute of Technology: https://bth.se/
• Muzinda Hub: https://x.com/muzindahub
• Treehouse: https://teamtreehouse.com/
• Django Software Foundation: https://www.djangoproject.com/foundation/
• Django Under the Hood: https://djangounderthehood.com/

Links from Django Girls+

• Coach at an event: https://coach.djangogirls.org/

• Organize an event: https://organize.djangogirls.org/

• Work on the website: https://github.com/DjangoGirls/djangogirls

• Contribute to our resources:

  • https://github.com/DjangoGirls/tutorial
  • https://github.com/DjangoGirls/coach-manual
  • https://github.com/DjangoGirls/organizer-manual

• Translate our resources:

  • https://github.com/DjangoGirls/translation-guide

• Donate to us:

  • https://www.patreon.com/djangogirls
  • https://donate.stripe.com/14kdTJ8PT6Fa3CwaEF
  • https://djangogirls.org/en/donate/donate/

• For corporate companies: https://djangogirls.org/en/donate/

That’s a lot of sites!

Yes, it is! 10+ years ago we migrated 200 sites to a new server - and in 2024 we set up Cloudflare protection for well over 1000 sites.

Aegir is a hosting system built in Drupal, for Drupal. It lets you create and manage Drupal sites and all their databases, filesystems and virtual hosts. With Aegir, it’s easy to manage hundreds or thousands of sites via a simple UI. Each site has a node to represent it, and this project stored a whole bunch of additional Cloudflare metadata against the Site Nodes.

Keeping a PaaS product online at all times comes with a high level of responsibility. After code quality assurance and testing, DDOS attacks of all sizes and types are a high risk threat. The cost of protecting our availability, unsurprisingly, was non-trivial and became a point requiring fresh research and investment. Reducing the general load and the potential attack load on our servers would serve to support our quality of service.

In the Spring of 2024 we set up a proof of concept using Cloudflare, which would allow us to make a significant ongoing cost saving whilst also playing with some really cool APIs.

The plan

In order to put all our sites behind Cloudflare, we needed to:

* Get Aegir talking to Cloudflare via their API, and build the automatic processes to support the setup process
* Create a clear interface for starting and tracking setup per site
* Create a clear dashboard for tracking progress overall
* Go! Change the nameserver records for every domain, to point to Cloudflare

Here are some of the key interesting parts of our story (which had negligible downtime, btw!)

Interacting with Cloudflare’s API

It was greatly pleasing to find that Cloudflare let you do almost everything over an API (given the right authentication!). Given the scale of their company, it shouldn’t be a huge surprise I suppose!

With 1000 sites approx. to deal with, there was a strong drive to automate as much of this process as possible. So there was much celebration when it became clear that we would be able to do almost every step automatically, including:

* create everything we needed for the site domain, with an appropriate plan under our chosen account
* upload DNS records, query them and update them
* perform real-time ownership verification and SSL validation

Simple admin setup - Obtain DNS records for hundreds of domains, store them against Site Nodes, press GO

A large portion of the domains (about 500) are under our control, so we were able to bulk export the DNS records, process and save them against their Aegir Site Nodes. Some simple processing removed the SOA and NS records so that we would be able to send the records straight to Cloudflare when setup started.
These ‘easy’ sites, for which we had the DNS records, would be processed in bulk with a lot of Go! button clicks, and then making the relevant nameserver changes with the domain provider.
(The domain provider did offer to do bulk updates for us, but there seemed to be a 24h delay before action was taken - so it was quicker to do these changes ourselves.)
 

Cropped screen grab of our progress pie chart

 

 

Creating a self-service setup mechanism via Drupal config + settings.php

Domains that we only had nameserver control for would have to be updated by the customer. But how would they know what nameservers to set up, and how would they trigger the setup process? Stats to the rescue!
As part of the Drupal 10 rebuild of the platform we added a Statistics module, which collects a selection of data points from each site and passes them to the corresponding node on Aegir for storage. They’re then aggregated and sent back to the sites so that customers can compare their performance to the cohort averages.
We created a form interface for the user to trigger setup when ready, and then smuggled the outputs over to Aegir in amongst the performance stats 🤭 

This self service route did still require a lot of chasing, but generally performed well as it allowed the users to perform the nameserver change at their choice of timing, rather than requiring scheduled calls and appointments on top of an already high administrative load.

Surfacing useful data, stats and buttons for the team

When developing a technical tool that ideally needs a single fire-and-forget button to kick things off, you not only need that one button but also a lot of clear visual cues to help others understand what’s going on.

We tied the setup steps to interface outputs, with clear dependency messaging and reporting.
Reporting eventually included a message in our Slack channel ⭐️
 

Our custom Aegir Site dashboard, with various setup steps all nice and green
The results

After just a few weeks, we had 990 sites set up on Cloudflare - 90% of the most important setups. It turned out to be very difficult to get hundreds of different people, groups and stakeholders to make DNS nameserver changes quickly (even when you tell them it’s urgent!), so the process would continue a little longer.

Already we can measure the success - thanks to Cloudflare’s caching, we’ve seen decent reductions in bandwidth use and the number of requests hitting the server.
 

Our Cloudflare Dashboard on the Production Aegir server. Inactive sites didn't need our fuller protection setup steps, so the blue and pink bars don't match exactly.

In a recent email, KDABian Leon Matthes highlighted some of his go-to command line tools for everyday use on Unix. His recommendations sparked a lively exchange among our colleagues, each sharing their own favorite utilities.

Many of these tools offer efficient alternatives to standard Unix programs, speeding up the workflow or otherwise enriching the development experience.

This article aims to serve as a resource for the wider community, encouraging others to explore these tools and upgrade their command line setup for improved productivity.

The following common Unix tools are listed in this document, with their alternatives specified in their respective sections:

• cd
• ls
• man
• find
• grep
• cat
• diff / git diff

Additionally, there are some tools here that do not replace common programs, but are extremely useful when working in a shell environment. These are broken into two broad categories:

• prompts & shells
• misc.

Many of these tools can be considered examples of the “rewrite it in Rust” approach (RIIR), which in this document will be denoted with Ferris the crab: 🦀

Finally, there is a bonus Rust crate listed at the end that is helpful for writing CLI programs of your own.

Note: for scripting, stick with standard Unix tools, as they’re more widely distributed and will work in most other Unix environments. The tools in this article are meant to improve quality of life working within your own shell environment on a daily basis.

cd autojump

autojump is an alternative to cd, invoked with the command j. It jumps to what it determines to be the best fit for whatever directory name you give it. For example, j cxx-qt will change directory to the cxx-qt directory, even if it’s nested several levels deep from the current working directory.

If autojump doesn’t prioritize a directory correctly, its priority weight can be increased or decreased. j -i XXX will increase the priority weight of the current working directory by XXX, while j -d XXX will do the opposite and decrease the weight accordingly.

autojump also supports opening a file browser at a matched location rather than cd‘ing into it, by invoking jo rather than j.

Unfortunately, autojump has not been in active development for the past two years, and can break in some environments. The next tool, zoxide, will be more reliable if autojump breaks for you.

zoxide 🦀

zoxide is a similar program to autojump, actually drawing inspiration from it. Invoked with the command z, it remembers paths that have been visited in the past and matches the best fitting directory. The tool also supports interactive selection of the correct match via the zi command, which uses the tool fzf for fuzzy finding. fzf is listed later in this article.

zoxide can also be used the same way as plain cd, and can target absolute and relative paths. It can be configured to be invoked from the j and ji commands, or even cd to fully replace the cd command.

Finally, it is implemented in Rust, resulting in better performance than autojump.

ls lsd 🦀

lsd is a more feature-rich version of ls, including colors, icons, tree-view, additional formatting, and more. It is also highly configurable through a yaml config file.

eza 🦀

eza is a small, fast ls rewrite that knows about symlinks, extended attributes, and git, and has support for hyperlinks. Similar to lsd, it supports colors and icons, which are configurable with a yaml config file.

man tldr

This project has several clients written in different languages. The most mature client is an npm package.

tldr is an alternative to using man for most common use cases. It is a collection of pages that provides brief descriptions and usage examples for loads of programs, standard Unix and otherwise. It’s much faster if you don’t need to read about every option in detail in order to find the correct way to invoke a command or select the proper option quickly.

For example, if the man page for tar is too long to read when looking for the right option to do something, simply running tldr tar will show a list of examples that will usually have the options you need.

cheat.sh / cht.sh

cheat.sh and its associated shellscript cht.sh, provide access to a superpowered aggregation of cheatsheets for programming languages and CLI tools, including tldr pages and other sources.

It has a great system for querying cheatsheets, and you don’t even need to install a tool (though you can), as the query response can be retrieved by curl. It’s also usable inside editors, for easy referencing while programming.

The cheatsheet sources also include StackOverflow answers, which allow for flexible usage like so:

$ cht.sh js parse json

A nice way to use cheat.sh without installing anything is to put the following function in your .bashrc or .zshrc:

function cheat() { if ! curl -s "cheat.sh/${*//\ /+}"; then echo "Failed to get the cheatsheet" >&2 return 1 fi }

Then you can use it like

$ cheat tar

or

$ cheat cpp number to string find fd 🦀

fd is an alternative for many use cases of find.

While it is not as powerful as find, it is designed to be faster and more user-friendly for the majority of find‘s use cases.

No more find -name .rs — just use fd .rs and you’re good to go.

fd is super fast and will search through your entire filesystem in a matter of seconds (Leon recorded 1.4s on his machine with 177GB of files).

By default, fd will not include any hidden files that are ignored by .gitignore, which is very useful as it doesn’t give you any random junk in your build directory and speeds up the search even further.

Use --hidden and --no-ignore (or -H and -I, respectively) to search for everything.

fzf

fzf is a fuzzy-finder that can match files, command history, processes, hostnames, bookmarks, git commits, and more, with interactive selection. It’s also usable as a vim or neovim plugin.

grep ripgrep 🦀

ripgrep (rg as a command) provides an incredibly fast grep alternative with a simpler interface.

Did you ever have to wait for grep to finish searching a directory or had to look up the right options for specific usage? Well, no more! Ripgrep will search the contents of large build directories within milliseconds.

Just running rg Q_PROPERTY will search through the entire current directory if you don’t pipe something into it, which is very convenient and the way it should have been in the first place. The output is also a lot friendlier and easier to read.

Like fd, use --hidden and --no-ignore to search in hidden and ignored directories/files.

cat bat 🦀

bat, written by the creator of fd, is a superpowered Rust rewrite of cat. It provides syntax highlighting, line numbers, support for displaying non-printable characters, support for showing multiple files at once, and pipes to less by default for large output. It can also be integrated with fzf, find, fd, ripgrep (rg), git show, git diff, man, and more. A tool you’ll read about later in this document, delta, uses bat as a dependency to display diffs.

diff / git diff diff-so-fancy

diff-so-fancy is an alternative to vanilla git diff that improves readability, with better formatting, colors, and highlighting. Configure git to use diffsofancy as its pager, and git diff will provide the more readable diffsofancy output.

delta 🦀

delta is an alternative to diffsofancy that’s written in Rust. It includes additional features, like line numbers, syntax highlighting, side-by-side, improved navigation between files in large diffs, hyperlinked commit hashes, improvements for display of git blame and merge conflicts, and the ability to syntax-highlight grep output. delta uses bat under the hood and, as such, they can share color themes.

prompts & shells starship 🦀

starship is a prompt written in Rust, which can be used with a number of popular shells including bash, zsh, fish, and even Windows shells like cmd and PowerShell.

The prompt is both stylish and informative, providing information like git branch, versioning, and more in the prompt itself. It also indicates the time length of command execution, whenever the run lasts for more than a few seconds — very helpful for gauging the duration of a build. This prompt should be utilized with a NerdFont for icon support.

Starship is also extremely configurable, so any details can be omitted or added; the look and feel of the prompt can be completely customized, etc.

zsh prompts & plugins

Some shell users argue that switching from bash is definitely worthwhile, with zsh being the favorite choice for many. It’s highly configurable and has a rich plugin ecosystem.

oh-my-zsh is a zsh framework that makes completions, searching in history, the prompt, etc., much nicer than the defaults. It can, of course, be tweaked much further from there. If you find oh-my-zsh to be a bit bloated, there are more lightweight alternatives such as ZimFW or Zinit.

Some zsh plugins can also serve as alternatives to previously mentioned tools. There are quite a few useful plugins listed here (they should work with any plugin manager): https://github.com/unixorn/awesome-zsh-plugins.

Some that stand out include:

• zsh-vi-mode
  • a proper Vim mode for the terminal, much better than the default one
• fast-syntax-highlighting
  • nice while-you-type syntax highlighting in the shell
• fzf-marks
  • alternative workflow to zoxide and similar cd improvements
  • this can also be used with bash
• zsh-autoenv
  • customize environment variables by directory, similar to the tool direnv mentioned later

Note: If you are interested in switching away from bash but don’t like zsh, consider trying fish.

Update Systems topgrade 🦀

topgrade is a tool which conveniently updates several package managers with one command.

Just run topgrade and every package manager under the sun will be updated, one after the other. This even includes flatpaks and updates to your systems package manager, very convenient.

Misc. direnv

direnv is an extension for several common Unix shells, focused on environment management. More specifically, it is intended to unclutter .profile and export different environment variables depending on the current directory.

On each prompt, it checks for the existence of a .envrc file in the current directory, otherwise looking for .env, and loads or unloads environment variables accordingly. It’s a single executable and very fast.

direnv is also extensible with bash files in .config.

blobdrop

blobdrop enables drag-n-drop of files from a terminal window, which can be very convenient when using the command line as a file browser. It was written by fellow kdabian Magnus Gross.

bonus! clap

bonus is not quite a tool, but a Rust crate used frequently for writing CLI tools, called clap.

clap is used in the codebases of a majority of the Rust tools in this document, as it’s incredibly useful. It’s the reason most Rust CLI tools have great UX.

Using the derive feature, you can simply mark up a struct of data you need from your command line arguments and clap will generate a beautiful and convenient CLI interface for you. Just take a look at the derive documentation to get an idea of what this looks like.

Other Tools

We hope these tools can improve your workflow, as they certainly make our lives on the command line far more enjoyable.

If you have any additions to this list, feel free to discuss them in the comments.

About KDAB

If you like this article and want to read similar material, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post CLI++: Upgrade Your Command Line appeared first on KDAB.

Following our announcement of the 6.x Steering Council elections, today we open candidate registrations. Registrations will be open until December 4 2024 at 23:59 Anywhere on Earth.

Register as a Steering Council candidate

Eligibility

Candidate eligibility requirements are defined in DEP 12: The Steering Council. To be qualified for elections, we require both of the following:

• A history of substantive contributions to Django or the Django ecosystem. This history must begin at least 18 months prior to the individual's candidacy for the Steering Council, and include substantive contributions in at least two of these bullet points:
  • Code contributions on Django projects or major third-party packages in the Django ecosystem
  • Reviewing pull requests and/or triaging Django project tickets
  • Documentation, tutorials or blog posts
  • Discussions about Django on the django-developers mailing list or the Django Forum
  • Running Django-related events or user groups
• A history of engagement with the direction and future of Django. This does not need to be recent, but candidates who have not engaged in the past three years must still demonstrate an understanding of Django's changes and direction within those three years.

If you have questions about the election please contact foundation@djangoproject.com or ask on the Django forum.

I'm excited to share the first version of Drupal Starshot's product strategy, a document that aims to guide the development and marketing of Drupal Starshot. To read it, download the full Drupal Starshot strategy document as a PDF (8 MB).

This strategy document is the result of a collaborative effort among the Drupal Starshot leadership team, the Drupal Starshot Advisory Council, and the Drupal Core Committers. We also tested it with marketers who provided feedback and validation.

Drupal Starshot and Drupal Core

Drupal Starshot is the temporary name for an initiative that extends the capabilities of Drupal Core. Drupal Starshot aims to broaden Drupal's appeal to marketers and a wider range of project budgets. Our ultimate goal is to increase Drupal's adoption, solidify Drupal's position as a leading CMS, and champion an Open Web.

For more context, please watch my DrupalCon Portland keynote.

It's important to note that Drupal Starshot and Drupal Core will have separate, yet complementary, product strategies. Drupal Starshot will focus on empowering marketers and expanding Drupal's presence in the mid-market, while Drupal Core will prioritize the needs of developers and more technical users. I'll write more about the Drupal Core product strategy in a future blog post once we have finalized it. Together, these two strategies will form a comprehensive vision for Drupal as a product.

Why a product strategy?

By defining our goals, target audience and necessary features, we can more effectively guide contributors and ensure that everyone is working towards a common vision. This product strategy will serve as a foundation for our development roadmap, our marketing efforts, enabling Drupal Certified Partners, and more.

Drupal Starshot product strategy TL;DR

For the detailed product strategy, please read the full Drupal Starshot strategy document (8 MB, PDF). Below is a summary.

Drupal Starshot aims to be the gold standard for marketers that want to build great digital experiences.

We'd like to expand Drupal's reach by focusing on two strategic shifts:

1. Prioritizing Drupal for content creators, marketers, web managers, and web designers so they can independently build websites. A key goal is to empower these marketing professionals to build and manage their websites independently without relying on developers or having to use the command line or an IDE.
2. Extending Drupal's presence in the mid-market segment, targeting projects with total budgets between $30,000 and $120,000 USD (€25,000 to €100,000).

Drupal Starshot will differentiate itself from competitors by providing:

1. A thoughtfully designed platform for marketers, balancing ease of use with flexibility. It includes smart defaults, best practices for common marketing tasks, marketing-focused editorial tools, and helpful learning resources.
2. A growth-oriented approach. Start simple with Drupal Starshot's user-friendly tools, and unlock advanced features as your site grows or you gain expertise. With sophisticated content modeling, efficient content reuse across channels, and robust integrations with other leading marketing technologies, ambitious marketers won't face the limitations of other CMSs and will have the flexibility to scale their site as needed.
3. AI-assisted site building tools to simplify complex tasks, making Drupal accessible to a wider range of users.
4. Drupal's existing competitive advantages such as extensibility, scalability, security, accessibility, multilingual support, and more.

What about ambitious site builders?

In the past, we used the term ambitious site builders to describe Drupal's target audience. Although this term doesn't appear in the product strategy document, it remains relevant.

While the strategy document is publicly available, it is primarily an internal guide. It outlines our plans but doesn't dictate our marketing language. Our product strategy's language purposly aligns with terms used by our target users, based on persona research and interviews.

To me, "ambitious site builders" includes all Drupal users, from those working with Drupal Core (more technically skilled) to those working with Drupal Starshot (less technical). Both groups are ambitious, with Drupal Starshot specifically targeting "ambitious marketers" or "ambitious no-code developers".

Give feedback

The product strategy is a living document, and we value input. We invite you to share your thoughts, suggestions, and questions in the product strategy feedback issue within the Drupal Starshot issue queue.

Get involved

There are many opportunities to get involved with Drupal Starshot, whether you're a marketer, developer, designer, writer, project manager, or simply passionate about the future of Drupal. To learn more about how you can contribute to Drupal Starshot, visit https://drupal.org/starshot.

Thank you

I'd like to thank the Drupal Starshot leadership team, the Drupal Starshot Advisory Council, and the Drupal Core Committers for their input on the strategy. I'm also grateful for the marketers who provided feedback on our strategy, helping us refine our approach.

We’re thrilled to introduce Stella Power, one of the newest members elected to the Drupal Association Board in October. Stella is the Managing Director of Annertech, a digital agency based in Dublin. She holds an MSc in Software Engineering from Dublin City University and a BA in Computational Physics from Trinity College Dublin. Since founding Annertech in 2008, she has grown the company into a team of approximately 40 members spanning the EU and beyond.

A passionate advocate for women in tech, Stella has been featured in numerous publications. In 2021, she was honored with the Women in Digital Award at Ireland’s National Digital Awards and, in 2022, received a Women in Drupal Award in the Scale category.

Stella is also an open-source evangelist and a sought-after speaker at international conferences, where she shares her expertise on development best practices, service delivery, data migrations, and security. She continues to contribute actively to Drupal and serves on the Drupal Security Team, the DrupalCon Europe Advisory Board, and the Starshot Advisory Council, in addition to her role on the Drupal Association Board.

We’re excited to have Stella on the Board, and she recently shared her insights on this new chapter in her journey:

What are you most excited about when it comes to joining the Drupal Association Board?
I’m looking forward to playing a role in shaping the future of Drupal. For me, Drupal is more than just a fantastic CMS—it’s a community. Being on the board gives me an opportunity to give back in a different way, stepping back to focus on the big picture. It’s not about concentrating on one part of the community or one piece of the codebase. I’m truly excited about this new role.

What do you hope to accomplish during your time on the board?
A big part of the Drupal Association's focus is fostering the growth of the Drupal community and supporting the project’s vision to create a safe, secure, and open web for everyone. As my role at Annertech changed from development to management, so did my contributions to Drupal. Instead of just contributing code I started contributing more to the community, most often in event organizing or on various committees. I contribute because I want to give back. The Drupal community has given me so much, even a career. I want to ensure others can benefit from it like I have.

I am a big advocate of getting new people involved. I love listening to new voices, and getting fresh perspectives on challenges or issues facing the Drupal community, and I look forward to helping grow the diversity of our community and amplifying voices that haven’t been heard before. The newer members of our community have a completely different take on what they want from Drupal. I look forward to listening to what they want, and to their ideas of Drupal and for Drupal.

What specific skill or perspective do you contribute to the board?
I have a coding background, and with that comes a built-in problem-solving radar. Developers tend to approach challenges like puzzles, and I’ve developed strong skills in context-switching. If something isn’t working I can change tack and come at it from a different angle. It was the logical, problem-solving aspect that first drew me to tech, and I’d like to think that that's a valuable skill.

How has Drupal impacted your life or career?
"If I hadn’t found Drupal I probably would have ended up doing something completely different with my life. I used to be an avid ceramic artist and amateur photographer. It was mainly just for fun, as a hobby, but I wanted to grow it into something more. However, it was when I went to build a website to showcase my portfolio that I found Drupal, and then it was contributing to Drupal that became my hobby!

I loved being involved in the community and contributing, but it wasn’t until I attended my first DrupalCon—in Szeged—that I realized it could be more than just a hobby. I was introduced to people who were doing such incredible things with Drupal, who were helping clients achieve their goals by creating incredible websites, and that’s when I decided to found my own digital agency and Annertech was born.

Tell us something that the Drupal community might not know about you.
I studied physics at university and initially aspired to be an astrophysicist. I even worked as an intern at the Space Telescope Science Institute with the Hubble Telescope! I loved the problem-solving aspects of physics, but Drupal allowed me to combine my love for problem-solving with my creative side.

Share a favorite quote or piece of advice that has inspired you.
I love the principle of aggregate marginal gains. It’s the idea that if you improve by just 1% consistently, those small gains will add up to remarkable improvement. We live in such a hectic world, where it's easy to feel overwhelmed or that challenges are insurmountable. Small improvements are far less daunting, and when you make small improvements on a daily basis, the overall results can be incredible.

We’re excited to see the amazing contributions Stella will make during her time on the Drupal Association Board. Thank you, Stella, for dedicating your time and expertise to serving the Drupal community! Connect with Stella on LinkedIn. 

The Drupal Association Board of Directors comprises 13 members with nine are nominated for staggered three-year terms, two are elected by Drupal Association members, and one seat is reserved for the Drupal Project Founder, Dries Buytaert, while another is reserved for the immediate past chair. The Board meets twice in person and four times virtually each year. It oversees policy development, executive director management, budget approvals, financial reporting, and fundraising efforts.

In the past week I had two people separately tell me what they thought the PSF Conduct WG did and both were wrong (and incidentally in the same way). As such, I wanted to clarify what exactly the WG does for people in case others also misunderstand what the group does.

⚠️I am a member of the PSF Conduct WG (whose membership you can see by checking the charter), and have been for a few years now. That means I both speak from experience but I also may be biased in some way that I&aposm not aware of. But since this post is meant to be objective I&aposm hoping there aren&apost any concerns about bias.&#x1F514;There are a myriad of conduct groups in the Python community beyond the PSF Conduct WG, and they all work differently. For example, conferences like PyCon US have their own, the Django and NumFOCUS communities have their own, etc. This post is about a specific group and does not represent other ones.

I would say there are 4 things the Conduct WG actually does (in order from least to most frequent):

1. Maintain the PSF Code of Conduct (CoC)
2. Let PSF members know when they have gone against the CoC in a public space
3. Record disciplinary actions taken by groups associated with the PSF
4. Provide conduct advice to Python groups

Let&aposs talk about what each of these mean.

Maintain the CoC

In September 2019 the CoC was rewritten from a two paragraph "don&apost be mean" CoC to a more professional one. That rewrite actually is what led to the establishment of the Conduct WG in the first place. Since then, the Conduct WG is in charge of making any changes as necessary to the document. But ever since the rewrite was completed, it is rarely touched.

Let PSF members know when they have gone against the CoC publicly

Becoming a member of the PSF requires that you "agree to the community Code of Conduct". As such, if you are found to be running afoul of the CoC publicly where you also declare your PSF membership, then the Conduct WG will reach out to you and kindly let you know what you did wrong and to please not do that (technically you could get referred to the PSF board to have your membership revoked if you did something really bad, but I&aposm not aware of that ever happening).

But there are two key details about this work of the WG that I think people don&apost realize that are important. One is the Conduct WG does not go out on the internet looking for members who have done something that&aposs in violation of the CoC. What happens instead is people report to the WG when they have seen a PSF member behave poorly in public while promoting their PSF membership (and this tends to be Fellows more than the general members).

Two, this is (so far) only an issue if you promote the fact that you&aposre a PSF member. What you do in your life outside of Python is none of the WG&aposs concern, but if you, e,g., call out your PSF affiliation on your profile on X and then post something that goes against the CoC, then that&aposs a problem as that then reflects poorly on the PSF and the rest of the membership. Now, if someone were to very publicly come out as a member of some heinous organization even without talking about Python then that might be enough to warrant the Conduct WG saying something to the PSF board (and this probably applies more to Fellows than general members), but I haven&apost seen that happen.

Record CoC violations

If someone violates the CoC, some groups report them to the Conduct WG and we record who violated the CoC, how they violated, and what action was taken. The reason for this is to see if someone is jumping from group to group, causing conduct issues, but in a way that the larger pattern isn&apost being noticed by individual groups. But to be honest, not many groups report things (it is one more thing to do after dealing with a conduct issue which is exhausting on its own), and typically people who run afoul of the CoC where a pattern would be big enough to cause concern usually do it enough in one place as well, so the misconduct is noticed regardless.

Provide advice

The most common thing the Conduct WG does, by far, is provide advice to other groups who ask us for said advice based on the WG&aposs training and expertise. This can range from, "can you double-check our logic and reaction as a neutral 3rd-party?" to, "can you provide a recommendation on how to handle this situation?"

While this might be the thing the Conduct WG does the most, it also seems to be the most misunderstood. For instance, much like with emailing PSF members when they have violated the CoC publicly while promoting their PSF membership, the Conduct WG does not go out looking for people causing trouble. This is entirely driven by people coming to the WG with a problem. The closest thing I can think of the Conduct WG doing in terms of proactively reaching out is some group that got a grant from the PSF Grants WG did something wrong around the CoC that was reported to the Conduct WG that warrants us notifying the Grants WG of the problem. But the Conduct WG isn&apost snooping around the internet looking for places to give advice.

I have also heard folks say the Conduct WG "demanded" something, or "made" something happen. That is simply not true. The Conduct WG has no power to compel some group to do something (i.e. things like moderation and enforcement is handled by the folks who come to the Conduct WG asking for advice). As an example, let&aposs say the Python steering council came to the Conduct WG asking for advice (and that could be as open-ended as "what do you recommend?" to "we are thinking of doing this; does that seem reasonable to you?"). The Conduct WG would provide the advice requested, and that&aposs the end of it. The Conduct WG advised in this hypothetical, it didn&apost require anything. The SC can choose to enact the advice, modify it in some way, or flat-out ignore it; the Conduct WG cannot make the SC do anything (heck, the SC isn&apost even under the PSF&aposs jurisdiction, but that&aposs not an important detail here, just something else I have heard people get wrong). And this inability to compel a group to do something even extends to groups that come to the Conduct WG for advice even if they are affiliated with the PSF. Going back to the Grants WG example, we can&apost make the Grants WG pull someone&aposs grant or deny future grants, we can just let them know what we think. We can refer an issue to the PSF board, but we can&apost compel the board to do anything (e.g., if we warn a PSF member about their public conduct, we can&apost make them stop being a PSF member for it, the most we can do is inform the PSF board about what someone has done and potentially offer advice).

Having said all of that, anecdotally it seems that most groups that request a recommendation from the Conduct WG enact those recommendations. So you could say the Conduct WG was involved in some action that was taken based on the WG&aposs recommendation, but you certainly cannot assign full blame on the WG for the actions taken by other groups either.

The Drupal Metatag module has been extended with a new submodule called Custom Meta. Custom Meta opens the way for the flexible definition of tags which can be used to drive custom applications outside the typical SEO requirements of a site.

This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler, “download now”.

This release focused on Python 3.13 support, but also on improved compatibility, made many performance optimizations, enhanced error reporting, and better debugging support.

Bug Fixes

• Windows: Fixed a regression in onefile mode that incorrectly handled program and command line paths containing spaces. Fixed in 2.4.4 already.

• Windows: Corrected an issue where console output handles were being opened with closed file handles. Fixed in 2.4.2 already.

• Standalone: Restored the ability to use trailing slashes on the command line to specify the target directory for data files on Windows. Fixed in 2.4.2 already.

• Compatibility: Fixed a parsing error that occurred with relative imports in .pyi files, which could affect some extension modules with available source code. Fixed in 2.4.3 already.

• Modules: Ensured that extension modules load correctly into packages when using Python 3.12. Fixed in 2.4.4 already.

• Windows: Improved command line handling for onefile mode to ensure full compatibility with quoting. Fixed in 2.4.4 already.

• Data Directories: Allowed the use of non-normalized paths on the command line when specifying data directories. Fixed in 2.4.5 already.

• Python 3.11+: Fixed an issue where inspect module functions could raise StopIteration when examining compiled functions on the stack. Fixed in 2.4.5 already.

• importlib_metadata: Improved compatibility with importlib_metadata by handling cases where it might be broken, preventing potential compilation crashes. Fixed in 2.4.5 already.

• Plugins: Fixed a crash that occurred when using the no_asserts YAML configuration option. Fixed in 2.4.6 already.

• Scons: Improved error tolerance when reading ccache log files to prevent crashes on Windows caused by non-ASCII module names or paths. Fixed in 2.4.11 already.

• Scons: Prevented the C standard option from being applied to C++ compilers, resolving an issue with the splash screen on Windows when using Clang. Fixed in 2.4.8 already.

• macOS: Enhanced handling of DLL self-dependencies to accommodate cases where DLLs use both .so and .dylib extensions for self-references. Fixed in 2.4.8 already.

• Compatibility: Fixed a memory leak that occurred when using deepcopy on compiled methods. Fixed in 2.4.9 already.

• MSYS2: Excluded the bin directory from being considered a system DLL folder when determining DLL inclusion. Fixed in 2.4.9 already.

• Python 3.10+: Fixed a crash that could occur when a match statement failed to match a class with arguments. Fixed in 2.4.9 already.

• MSYS2: Implemented a workaround for non-normalized paths returned by os.path.normpath in MSYS2 Python environments. Fixed in 2.4.11 already.

• Python 3.12: Resolved an issue where Nuitka’s constant code was triggering assertions in Python 3.12.7. Fixed in 2.4.10 already.

• UI: Ensured that the --include-package option includes both Python modules and extension modules that are sub-modules of the specified package. Fixed in 2.4.11 already.

• Windows: Prevented encoding issues with CMD files used for accelerated mode on Windows.

• Standalone: Improved the standard library scan to avoid assuming the presence of specific files, which might have been deleted by the user or a Python distribution.

• Compatibility: Added suffix, suffixes, and stem attributes to Nuitka resource readers to improve compatibility with file objects.

• Compatibility: Backported the error message change for yield from used at the module level, using dynamic detection instead of hardcoded text per version.

• Compatibility: Fixed an issue where calling built-in functions with keyword-only arguments could result in errors due to incorrect argument passing.

• Compatibility: Fixed reference leaks that occurred when using list.insert and list.index with 2 or 3 arguments.

• Windows: Prioritized relative paths over absolute paths for the result executable when absolute paths are not file system encodable. This helps address issues related to non-ASCII short paths on some Chinese systems.

• Compatibility: Improved compatibility with C extensions by handling cases where the attribute slot is not properly implemented, preventing potential segfaults.

• Compatibility: Prevent the leakage of sys.frozen when using the multiprocessing module and its plugin, resolving a long-standing TODO and potentially breaking compatibility with packages that relied on this behavior.

• Compatibility: Fixed an issue where matching calls with keyword-only arguments could lead to incorrect optimization and argument passing errors.

• Compatibility: Corrected the handling of iterators in for loops to avoid assuming the presence of slots, preventing potential issues.

• macOS: Added support for cyclic DLL dependencies, where DLLs have circular references.

• Compatibility: Ensured the use of updated expressions during optimization phase for side effects to prevent crashes caused by referencing obsolete information.

• Python 3.10+: Fixed a crash that could occur in complex cases when re-formulating match statements.

• Python 3.4-3.5: Corrected an issue in Nuitka’s custom PyDict_Next implementation that could lead to incorrect results in older Python 3 versions.

• Python 3.10+: Ensured that AttributeError is raised with the correct keyword arguments, avoiding a TypeError that occurred previously.

• Plugins: Added a data file function that avoids loading packages, preventing potential crashes caused by incompatible dependencies (e.g., numpy versions).

• Compatibility: Ensured that Nuitka’s package reader closes data files after reading them to prevent resource warnings in certain Python configurations.

• Standalone: Exposed setuptools contained vendor packages in standalone distributions to match the behavior of the setuptools package.

• Accelerated Mode: Enabled the django module parameter in accelerated mode to correctly detect used extensions.

• Compatibility: Prevented resource warnings for unclosed files when trace outputs are sent to files via command line options.

• Compatibility: Enabled the use of xmlrpc.server without requiring the pydoc module.

• Plugins: Fixed an issue in the anti-bloat configuration where change_function and change_classes ignored “when” clauses, leading to unintended changes.

• Python 3.12 (Linux): Enhanced static libpython handling for Linux. Static libpython is now used only when the inline copy is available (not in official Debian packages). The inline copy of hacl is used for all Linux static libpython uses with Python 3.12 or higher.

• Standalone: Further improved the standard library scan to avoid assuming the presence of files that might have been manually deleted.

• UI: Fixed the --include-raw-dir option, which was not functioning correctly. Only the Nuitka Package configuration was being used previously.

Package Support

• arcade: Improved standalone configuration for the arcade package. Added in 2.4.3 already.

• license-expression: Added a missing data file for the license-expression package in standalone distributions. Added in 2.4.6 already.

• pydantic: Included a missing implicit dependency required for deprecated decorators in the pydantic package to function correctly in standalone mode. Fixed in 2.4.5 already.

• spacy: Added a missing implicit dependency for the spacy package in standalone distributions. Added in 2.4.7 already.

• trio: Updated standalone support for newer versions of the trio package. Added in 2.4.8 already.

• tensorflow: Updated standalone support for newer versions of the tensorflow package. Added in 2.4.8 already.

• pygame-ce: Added standalone support for the pygame-ce package. Added in 2.4.8 already.

• toga: Added standalone support for newer versions of the toga package on Windows. Added in 2.4.9 already.

• django: Implemented a workaround for a django debug feature that attempted to extract column numbers from compiled frames. Added in 2.4.9 already.

• PySide6: Improved standalone support for PySide6 on macOS by allowing the recognition of potentially unusable plugins. Added in 2.4.9 already.

• polars: Added a missing dependency for the polars package in standalone distributions. Added in 2.4.9 already.

• django: Enhanced handling of cases where the django settings module parameter is absent in standalone distributions. Added in 2.4.9 already.

• win32ctypes: Included missing implicit dependencies for win32ctypes modules on Windows in standalone distributions. Added in 2.4.9 already.

• arcade: Added a missing data file for the arcade package in standalone distributions. Added in 2.4.9 already.

• PySide6: Allowed PySide6 extras to be optional on macOS in standalone distributions, preventing complaints about missing DLLs when they are not installed. Added in 2.4.11 already.

• driverless-selenium: Added standalone support for the driverless-selenium package. Added in 2.4.11 already.

• tkinterdnd2: Updated standalone support for newer versions of the tkinterdnd2 package. Added in 2.4.11 already.

• kivymd: Updated standalone support for newer versions of the kivymd package. Added in 2.4.11 already.

• gssapi: Added standalone support for the gssapi package. Added in 2.4.11 already.

• azure.cognitiveservices.speech: Added standalone support for the azure.cognitiveservices.speech package on macOS.

• mne: Added standalone support for the mne package.

• fastapi: Added a missing dependency for the fastapi package in standalone distributions.

• pyav: Updated standalone support for newer versions of the pyav package.

• py_mini_racer: Added standalone support for the py_mini_racer package.

• keras: Improved standalone support for keras by extending its sub-modules path to include the keras.api sub-package.

• transformers: Updated standalone support for newer versions of the transformers package.

• win32com.server.register: Updated standalone support for newer versions of the win32com.server.register package.

• Python 3.12+: Added support for distutils in setuptools for Python 3.12 and later.

• cv2: Enabled automatic scanning of missing implicit imports for the cv2 package in standalone distributions.

• lttbc: Added standalone support for the lttbc package.

• win32file: Added a missing dependency for the win32file package in standalone distributions.

• kivy: Fixed an issue where the kivy clipboard was not working on Linux due to missing dependencies in standalone distributions.

• paddleocr: Added missing data files for the paddleocr package in standalone distributions.

• playwright: Added standalone support for the playwright package with a new plugin.

• PySide6: Allowed PySide6 extras to be optional on macOS in standalone distributions, preventing complaints about missing DLLs when they are not installed.

New Features

• Python 3.13: Added experimental support for Python 3.13.

  Warning

  Python 3.13 support is not yet recommended for production use due to limited testing. On Windows, only MSVC and ClangCL are currently supported due to workarounds needed for incompatible structure layouts.

• UI: Introduced a new --mode selector to replace the options --standalone, --onefile, --module, and --macos-create-app-bundle.

  Note

  The app mode creates an app bundle on macOS and a onefile binary on other operating systems to provide the best deployment option for each platform.

• Windows: Added a new hide choice for the --windows-console-mode option. This generates a console program that hides the console window as soon as possible, although it may still briefly flash.

• UI: Added the --python-flag=-B option to disable the use of bytecode cache (.pyc) files during imports. This is mainly relevant for accelerated mode and dynamic imports in non-isolated standalone mode.

• Modules: Enabled the generation of type stubs (.pyi files) for compiled modules using an inline copy of stubgen. This provides more accurate and informative type hints for compiled code.

  Note

  Nuitka also adds implicit imports to compiled extension modules, ensuring that dependencies are not hidden.

• Plugins: Changed the data files configuration to a list of items, allowing the use of when conditions for more flexible control. Done in 2.4.6 already.

• Onefile: Removed the MSVC requirement for the splash screen in onefile mode. It now works with MinGW64, Clang, and ClangCL. Done for 2.4.8 already.

• Reports: Added information about the file system encoding used during compilation to help debug encoding issues.

• Windows: Improved the attach mode for --windows-console-mode when forced redirects are used.

• Distutils: Added the ability to disable Nuitka in pyproject.toml builds using the build_with_nuitka setting. This allows falling back to the standard build backend without modifying code or configuration. This setting can also be passed on the command line using --config-setting.

• Distutils: Added support for commercial file embedding in distutils packages.

• Linux: Added support for using uninstalled self-compiled Python installations on Linux.

• Plugins: Enabled the matplotlib plugin to react to active Qt and tkinter plugins for backend selection.

• Runtime: Added a new original_argv0 attribute to the __compiled__ value to provide access to the original start value of sys.argv[0], which might be needed by applications when Nuitka modifies it to an absolute path.

• Reports: Added a list of DLLs that are actively excluded because they are located outside of the PyPI package.

• Plugins: Allowed plugins to override the compilation mode for standard library modules when necessary.

Optimization

• Performance: Implemented experimental support for “dual types”, which can significantly speed up integer operations in specific cases (achieving speedups of 12x or more in some very specific loops). This feature is still under development but shows promising potential for future performance gains, esp. when combined with future PGO (Profile Guided Optimization) work revealing likely runtime types more often and more types being covered.

• Performance: Improved the speed of module variable access.

  • For Python 3.6 to 3.10, this optimization utilizes dictionary version tags but may be less effective when module variables are frequently written to.

  • For Python 3.11+, it relies on dictionary key versions, making it less susceptible to dictionary changes but potentially slightly slower for cache hits compared to Python 3.10.

• Performance: Accelerated string dictionary lookups for Python 3.11+ by leveraging knowledge about the key and the module dictionary’s likely structure. This also resolves a previous TODO item, where initial 3.11 support was not as fast as our support for 3.10 was in this domain.

• Performance: Optimized module dictionary updates to occur only when values actually change, improving caching efficiency.

• Performance: Enhanced exception handling by removing bloat in the abstracted differences between Python 3.12 and earlier versions. This simplifies the generated C code, reduces conversions, and improves efficiency for all Python versions. This affects both C compile time and runtime performance favorably and solves a huge TODO for Python 3.12 performance.

• Performance: Removed the use of CPython APIs calls for accessing exception context and cause values, which can be slow.

• Performance: Utilized Nuitka’s own faster methods for creating int and long values, avoiding slower CPython API calls.

• Performance: Implemented a custom variant of _PyGen_FetchStopIterationValue to avoid CPython API calls in generator handling, further improving performance on generators, coroutines and asyncgen.

• Windows: Aligned with CPython’s change in reference counting implementation on Windows for Python 3.12+, which improves performance with LTO (Link Time Optimization) enabled.

• Optimization: Expanded static optimization to include unary operations, improving the handling of number operations and preparing for full support of dual types.

• Optimization: Added static optimization for os.stat and os.lstat calls.

• Performance: Passed the exception state directly into unpacking functions, eliminating redundant exception fetching and improving code efficiency.

• Performance: Introduced a dedicated helper for unpacking length checks, resulting in faster and more compact code helping scalability as well.

• Performance: Generated more efficient code for raising built-in exceptions by directly creating them through the base exception’s new method instead of calling them as functions. This can speed up some things by a lot.

• Performance: Optimized exception creation by avoiding unnecessary tuple allocations for empty exceptions. This hack avoids hitting the memory allocator as much.

• Performance: Replaced remaining uses of PyTuple_Pack with Nuitka’s own helpers to avoid CPython API calls.

• Code Generation: Replaced implicit exception raise nodes with direct exception creation nodes for improved C code generation.

• Windows: Aligned with CPython’s change in managing object reference counters on Windows for Python 3.12+, improving performance with LTO enabled.

• Performance: Removed remaining CPython API calls when creating int values in various parts of the code, including specialization code, helpers, and constants loading.

• Windows: Avoided scanning for DLLs in the PATH environment variable when they are not intended to be used from the system. This prevents potential crashes related to non-encodable DLL paths and makes those scans faster too.

• Windows: Updated to a newer MinGW64 version from 13.2 to 14.2 for potentially improved binary code generation with that compiler.

• Code Size: Reduced the size of constant blobs by avoiding module-level constants for the global values -1, 0, and 1.

• Code Generation: Improved code generation for variables by directly placing NameError exceptions into the thread state when raised, making for more compact C code.

• Optimization: Statically optimized the sys.ps1 and sys.ps2 values to not exist (unless in module mode), potentially enabling more static optimization in packages that detect interactive usage checking them.

• Performance: Limited the use of tqdm locking to no-GIL and Scons builds where threading is actively used.

• Optimization: Implemented a faster check for non-frame statement sequences by decoupling frames and normal statement sequences and using dedicated accessors. This improves performance during the optimization phase.

Anti-Bloat

• Prevented the inclusion of importlib_metadata for the numpy package. Added in 2.4.2 already.

• Avoided the use of dask in the pandera package. Added in 2.4.5 already.

• Removed numba for newer versions of the shap package. Added in 2.4.6 already.

• Prevented attempts to include both Python 2 and Python 3 code for the aenum package, avoiding SyntaxError warnings. Added in 2.4.7 already.

• Enhanced handling for the sympy package. Added in 2.4.7 already.

• Allowed pydoc for the pyqtgraph package. Added in 2.4.7 already.

• Avoided pytest in the time_machine package. Added in 2.4.9 already.

• Avoided pytest in the anyio package.

• Avoided numba in the pandas package.

• Updated anti-bloat measures for newer versions of the torch package with increased coverage.

• Avoided pygame.tests and cv2 for the pygame package.

• Allowed unittest in the absl.testing package.

• Allowed setuptools in the tufup package.

• Avoided test modules when using the bsdiff4 package.

• Treated the use of the wheel module the same as using the setuptools package.

Organizational

• Development Environment: Added experimental support for a devcontainer to the repository, providing an easier way to set up a Linux-based development environment. This feature is still under development and may require further refinement.

• Issue Reporting: Clarified the issue reporting process on GitHub, emphasizing the importance of testing reproducers against Python first to ensure the issue is related to Nuitka.

• Issue Reporting: Discouraged the use of --deployment in issue reports, as it hinders the automatic identification of issues, that should be the first thing to remove.

• UI: Improved the clarity of help message of the option for marking data files as external, emphasizing that files must be included before being used.

• UI: Added checks to the Qt plugins to ensure that specified plugin families exist, preventing unnoticed errors.

• UI: Implemented heuristic detection of terminal link support, paving the way for adding links to options and groups in the command line interface.

• UI: Removed obsolete caching-related options from the help output, as they have been replaced by more general options.

• Plugins: Improved error messages when retrieving information from packages during compilation.

• Quality: Implemented a workaround for an isort bug that prevented it from handling UTF-8 comments.

• Quality: Updated GitHub actions to use clang-format-20.

• Quality: Updated to the latest version of black for code formatting.

• Release Process: Updated the release script tests for Debian and PyPI to use the correct runner names. (Changed in 2.4.1 already.

• UI: Disabled progress bar locking, as Nuitka currently doesn’t utilize threads.

• UI: Added heuristic detection of terminal link support and introduced an experimental terminal link as a first step towards a more interactive command line interface.

• Debugging: Fixed a crash in the “explain reference counts” feature that could occur with unusual dict values mistaken for modules.

• Debugging: Included reference counts of tracebacks when dumping reference counts at program end.

• Debugging: Added assertions and traces to improve debugging of input/output handling.

• Quality: Added checks for configuration module names in Nuitka package configuration to catch errors caused by using filenames instead of module names.

• UI: Removed obsolete options controlling cache behavior, directing users to the more general cache options.

• Scons: Ensured that the CC environment variable is used consistently for --version and onefile bootstrap builds, as well as the Python build, preventing inconsistencies in compiler usage and outputs.

• Distutils: Added the compiled-package-hidden-by-package mnemonic for use in distutils to handle the expected warning when a Python package is replaced with a compiled package and the Python code is yet to be deleted.

• Dependency Management: Started experimental support for downloading Nuitka dependencies like ordered-set. This feature is not yet ready for general use.

Tests

• Added Python 3.13 to the GitHub Actions test matrix.

• Significantly enhanced construct-based tests for clearer results. The new approach executes code with a boolean flag instead of generating different code, potentially leading to the removal of custom templating.

• Removed the 2to3 conversion code from the test suite, as it is being removed from newer Python versions. Tests are now split with version requirements as needed.

• Fixed an issue where the test runner did not discover and use Python 3.12+, resulting in insufficient test coverage for those versions on GitHub Actions.

• Ensured that the compare_with_cpython test function defaults to executing the system’s Python interpreter instead of relying on the PYTHON environment variable.

• Set up continuous integration with Azure Pipelines to run Nuitka tests against the factory branch on each commit.

• Enforced the use of static libpython for construct-based tests to eliminate DLL call overhead and provide more accurate performance measurements.

• Improved the robustness of many construct tests, making them less sensitive to unrelated optimization changes.

• Removed a test that was only applicable to Nuitka Commercial, as it was not useful to always skip it in the standard version. Commercial tests are now also recognized by their names.

• Added handling for segmentation faults in distutils test cases, providing debug output for easier diagnosis of these failures.

• Prevented resource warnings for unclosed files in a reflected test.

Cleanups

• WASI: Corrected the signatures of C function getters and setters for compiled types in WASI to ensure they match the calling conventions. Casts are now performed locally to the compiled types instead of in the function signature. Call entries also have the correct signature used by Python C code.

• WASI: Improved code cleanliness by adhering to PyCFunction signatures in WASI.

• Code Generation: Fixed a regression in code generation that caused misaligned indentation in some cases.

• Code Formatting: Changed some code for identical formatting with clang-format-20 to eliminate differences between the new and old versions.

• Caching: Enforced proper indentation in Nuitka cache files stored in JSON format.

• Code Cleanliness: Replaced checks for Python 3.4 or higher with checks for Python 3, simplifying the code and reflecting the fact that Python 3.3 is no longer supported.

• Code Cleanliness: Removed remaining Python 3.3 specific code from frame templates.

• Code Cleanliness: Performed numerous spelling corrections and renamed internal helper functions for consistency and clarity.

• Plugins: Renamed the get_module_directory helper function in the Nuitka Package configuration to remove the leading underscore, improving readability.

• Plugins: Moved the numexpr.cpuinfo workaround to the appropriate location in the Nuitka Package configuration, resolving an old TODO item.

Summary

This a major release that brings support for Python 3.13, relatively soon after its release.

Our plugin system and Nuitka plugin configuration was used a lot for support of many more third-party packages, and numerous other enhancements in the domain of avoiding bloat.

This release focuses on improved compatibility, new break through performance optimizations, to build on in the future, enhanced error reporting, and better debugging support.