FLOSS Project Planets

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

DrupalCon Barcelona 2024 Driesnote presentation

Approximately 1,100 Drupal enthusiasts gathered in Barcelona, Spain, last week for DrupalCon Europe. As per tradition, I delivered my State of Drupal keynote, often referred to as the "DriesNote".

If you missed it, you can watch the video or download my slides (177 MB).

In my keynote, I gave an update on Drupal Starshot, an ambitious initiative we launched at DrupalCon Portland 2024. Originally called Drupal Starshot, inspired by President Kennedy's Moonshot challenge, the product is now officially named Drupal CMS.

The goal of Drupal CMS is to set the standard for no-code website building. It will allow non-technical users, like marketers, content creators, and site builders, to create digital experiences with ease, without compromising on the power and flexibility that Drupal is known for.

A four-month progress report

A preview of Drupal.org's front page with the updated Drupal brand and content.

While Kennedy gave NASA eight years, I set a goal to deliver the first version of Drupal CMS in just eight months. It's been four months since DrupalCon Portland, which means we're halfway through.

So in my keynote, I shared our progress and gave a 35-minute demo of what we've built so far. The demo highlights how a fictional marketer, Sarah, can build a powerful website in just hours with minimal help from a developer. Along her journey, I showcased the following key innovations:

1. A new brand for a new market: A brand refresh of Drupal.org, designed to appeal to both marketers and developers. The first pages are ready and available for preview at new.drupal.org, with more pages launching in the coming months.
2. A trial experience: A trial experience that lets you try Drupal CMS with a single click, eliminating long-standing adoption barriers for new users. Built with WebAssembly, it runs entirely in the browser – no servers to install or manage.
3. An improved installer: An installer that lets users install recipes – pre-built features that combine modules, configuration, and default content for common website needs. Recipes bundle years of expertise into repeatable, shareable solutions.
4. Events recipe: A simple events website that used to take an experienced developer a day to build can now be created in just a few clicks by non-developers.
5. Project Browser support for recipes: Users can now browse the Drupal CMS recipes in the Project Browser, and install them in seconds.
6. First page of documentation: New documentation created specifically for end users. Clear, effective documentation is key to Drupal CMS's success, so we began by writing a single page as a model for the quality and style we aim to achieve.
7. AI for site building: AI agents capable of creating content types, configuring fields, building Views, forms, and more. These agents will transform how people build and manage websites with Drupal.
8. Responsible AI policy: To ensure responsible AI development, we've created a Responsible AI policy. I'll share more details in an upcoming blog, but the policy focuses on four key principles: human-in-the-loop, transparency, swappable large language models (LLMs), and clear guidance.
9. SEO Recipe: Combines and configures all the essential Drupal modules to optimize a Drupal site for search engines.
10. 14 recipes in development: In addition to the Events and SEO recipes, 12 more are in development with the help of our Drupal Certified Partners. Each Drupal CMS recipe addresses a common marketing use case outlined in our product strategy. We showcased both the process and progress during the Initiative Lead Keynote for some of the tracks. After DrupalCon, we'll begin developing even more recipes and invite additional contributors to join the effort.
11. AI-assisted content migration: AI will crawl your source website and handle complex tasks like mapping unstructured HTML to structured Drupal content types in your destination site, making migrations faster and easier. This could be a game-changer for website migrations.
12. Experience Builder: An early preview of a brand new, out-of-the-box tool for content creators and designers, offering layout design, page building, basic theming and content editing tools. This is the first time I've showcased our progress on stage at a DrupalCon.
13. Future-proof admin UI with React: Our strategy for modernizing Drupal's backend UI with React.
14. The "Adopt-a-Document" initiative: A strategy and funding model for creating comprehensive documentation for Drupal CMS. If successful, I'm hopeful we can expand this model to other areas of Drupal. For more details, please read the announcement on drupal.org.
15. Global Documentation Lead: The Drupal Association's commitment to hire a dedicated Documentation Lead, responsible for managing all aspects of Drupal's documentation, beyond just Drupal CMS.

The feedback on my presentation has been incredible, both online and in-person. The room was buzzing with energy and positivity! I highly recommend watching the recording.

Attendees were especially excited about the AI capabilities, Experience Builder, and recipes. I share their enthusiasm as these capabilities are transformative for Drupal.

Many of these features are designed with non-developers in mind. Our goal is to broaden Drupal's reach beyond its traditional user base and reach more people than ever before.

Release schedule

Our launch plan targets Drupal CMS's release on Drupal's upcoming birthday: January 15, 2025. It's also just a couple of weeks after the Drupal 7 End of Life, marking the end of one era and the beginning of another.

The next milestone is DrupalCon Singapore, taking place from December 9–11, 2024, less than 3 months away. We hope to have a release candidate ready by then.

Now that we're back from DrupalCon and have key milestone dates set, there is a lot to coordinate and plan in the coming weeks, so stay tuned for updates.

Call for contribution

Ambitious? Yes. But achievable if we work together. That's why I'm calling on all of you to get involved with Drupal CMS. Whether it's building recipes, enhancing the Experience Builder, creating AI agents, writing tests, improving documentation, or conducting usability testing – there are countless ways to contribute and make a difference. If you're ready to get involved, visit https://drupal.org/starshot to learn how to get started.

Thank you

This effort has involved so many people that I can't name them all, but I want to give a huge thank you to the Drupal CMS Leadership Team, who I've been working with closely every week: Cristina Chumillas (Lullabot), Gábor Hojtsy (Acquia), Lenny Moskalyk (Drupal Association), Pamela Barone (Technocrat), Suzanne Dergacheva (Evolving Web), and Tim Plunkett (Acquia).

A special shoutout goes to the demo team we assembled for my presentation: Adam Hoenich (Acquia), Amber Matz (Drupalize.me), Ash Sullivan (Acquia), Jamie Abrahams (FreelyGive), Jim Birch (Kanopi), Joe Shindelar (Drupalize.me), John Doyle (Digital Polygon), Lauri Timmanee (Acquia), Marcus Johansson (FreelyGive), Martin Anderson-Clutz (Acquia), Matt Glaman (Acquia), Matthew Grasmick (Acquia), Michael Donovan (Acquia), Tiffany Farriss (Palantir.net), and Tim Lehnen (Drupal Association).

I also want to thank the Drupal CMS track leads and contributors for their development work. Additionally, I'd like to recognize the Drupal Core Committers, Drupal Association staff, Drupal Association Board of Directors, and Certified Drupal Partners for continued support and leadership. There are so many people and organizations whose contributions deserve recognition that I can't list everyone individually, partly to avoid the risk of overlooking anyone. Please know your efforts are deeply appreciated.

Lastly, thank you to everyone who helped make DrupalCon Barcelona a success. It was excellent!

Fourteen new GNU releases in the last month (as of September 30, 2024):

Fourteen new GNU releases in the last month (as of September 30, 2024):

Drupal's form API has been brilliant for many years. Still, recently I found myself wondering why I needed to build a configuration form if I already had a schema for my config. Defining a schema facilitates API-first validation (including some pretty smart constraints), specific typing (e.g. actual booleans or integers instead of '0' or '1' strings), and even translation in Drupal. 

That last part got me thinking; if Drupal automatically provides translation forms for typed configuration, why must I build a form? I started diving into the code and found config_translation_config_schema_info_alter() which maps certain config data types to element classes. The ConfigTranslationFormBase::buildForm() class fetches the schema for each config property from the 'config.typed' service (\Drupal\Core\Config\TypedConfigManager) before building the appropriate elements. So Drupal core automatically provides this translation form - notice the long textarea for the 'body' property:

Screenshot of a config translation form from Drupal core

I had built a block plugin that needed some regex-based validation on a couple of its configuration properties. Validation constraints seemed like a natural fit for these, as an inherent part of the property definitions, rather than just on the form level. Drupal has had good support for validation constraints on configuration since version 10.2. This allows forms to be simpler, and config to be fully validatable, even outside the context of a form (e.g. for setting via APIs or config synchronisation). So I defined my config schema like this:

block.settings.mymodule_myblock: type: block_settings label: 'MyBlock block settings' mapping: svcid: type: string label: 'Service ID' constraints: Regex: pattern: '/^[a-zA-Z0-9_\-]+$/' message: "The %value can only contain simple letters, numbers, underscores or hyphens." default: 'abcde' locked: true envid: type: string label: 'Environment ID' constraints: Regex: pattern: '/^[a-zA-Z0-9_\-]+$/' message: "The %value can only contain simple letters, numbers, underscores or hyphens." default: 'x-j9WsahRe_1An51DhErab-C'

Then I set myself the challenge of building a configuration form 'automatically' from this schema - without using core's config_translation module at all, as this was for a monolingual site. 

I only had two string properties, which meant two textfields, but I wrote the code to use form elements that could be appropriate for other types of property that might get added in the future. The #title of each element could come directly from each label in the schema. (Why do we usually set these in both the schema and form element?!) I added custom default and locked properties to the schema to help encapsulate everything I considered 'inherent' to each part of the config in one place. This meant the configuration form for my block could be fairly simple:

public function blockForm($form, FormStateInterface $form_state) { // Each config property will be returned with its schema from $this->getConfigurables(). foreach ($this->getConfigurables() as $key => $schema_info) { $form[$key] = [ '#type' => match ($schema_info['type']) { 'string', 'label' => 'textfield', 'text' => 'textarea', 'boolean' => 'checkbox', 'integer', 'float' => 'number', 'email' => 'email', }, '#title' => $schema_info['label'], '#default_value' => $this->configuration[$key], '#required' => empty($schema_info['nullable']), '#disabled' => $schema_info['locked'] ?? FALSE, ]; } return $form; }

Hopefully that gives an idea of how simple a config form could be - and this could really be reduced further by refactoring it into a generic trait. The code in core's config_translation module for mapping the type of each property to an element type could be much more useful than the fairly naïve match statement above, if it was refactored out to be available even to monolingual sites.

You can explore my full code at https://gist.github.com/anotherjames/bcb7ba55ec56359240b26d322fe2f5a5. That includes the getConfigurables() method which pulls the schema from the TypedConfigManager.

You'll see that I went a little further and picked up the regex constraints for each config property, for use in #pattern form API properties. This provides quick feedback to admins about what characters are allowed using the HTML5 pattern attribute:

Not all configuration constraints could be built into the form level. It's arguable that since the Regex constraint and HTML pattern attribute support slightly different regular expression features, this particular one shouldn't be included in a generic trait. Then again, the Choice constraint could be especially useful to include, as it could be used to populate #options for select, radios, or checkboxes elements. We've started using backed Enums with labels for fixed sets of options. Can we wire those up to choice constraints together, I wonder?

Whereas my example was for a configurable plugin's form (which I don't believe can use #config_target), Joachim Noreiko (joachim) has submitted a feature request to Drupal core for forms extending ConfigFormBase to get automatically built from schema. This idea of generating form elements from config schema is still in its infancy, so its limits and benefits need to be explored further. Please let us know in a comment here, or in Joachim's feature request, if you have done anything similar, or have ideas or concerns to point out!

When working with strings in Python, you may need to interpolate values into your string and format these values to create new strings dynamically. In modern Python, you have f-strings and the .format() method to approach the tasks of interpolating and formatting strings.

In this tutorial, you’ll learn how to:

• Use f-strings and the .format() method for string interpolation
• Format the interpolated values using replacement fields
• Create custom format specifiers to format your strings

To get the most out of this tutorial, you should know the basics of Python programming and the string data type.

Get Your Code: Click here to download the free sample code that shows you how to use modern string formatting tools in Python.

Take the Quiz: Test your knowledge with our interactive “A Guide to Modern Python String Formatting Tools” quiz. You’ll receive a score upon completion to help you track your learning progress:

Interactive Quiz

A Guide to Modern Python String Formatting Tools

You can take this quiz to test your understanding of modern tools for string formatting in Python. These tools include f-strings and the .format() method.

Getting to Know String Interpolation and Formatting in Python

Python has developed different string interpolation and formatting tools over the years. If you’re getting started with Python and looking for a quick way to format your strings, then you should use Python’s f-strings.

Note: To learn more about string interpolation, check out the String Interpolation in Python: Exploring Available Tools tutorial.

If you need to work with older versions of Python or legacy code, then it’s a good idea to learn about the other formatting tools, such as the .format() method.

In this tutorial, you’ll learn how to format your strings using f-strings and the .format() method. You’ll start with f-strings to kick things off, which are quite popular in modern Python code.

Using F-Strings for String Interpolation

Python has a string formatting tool called f-strings, which stands for formatted string literals. F-strings are string literals that you can create by prepending an f or F to the literal. They allow you to do string interpolation and formatting by inserting variables or expressions directly into the literal.

Creating F-String Literals

Here you’ll take a look at how you can create an f-string by prepending the string literal with an f or F:

Python 👇 >>> f"Hello, Pythonista!" 'Hello, Pythonista!' 👇 >>> F"Hello, Pythonista!" 'Hello, Pythonista!' Copied!

Using either f or F has the same effect. However, it’s a more common practice to use a lowercase f to create f-strings.

Just like with regular string literals, you can use single, double, or triple quotes to define an f-string:

Python 👇 >>> f'Single-line f-string with single quotes' 'Single-line f-string with single quotes' 👇 >>> f"Single-line f-string with double quotes" 'Single-line f-string with single quotes' 👇 >>> f'''Multiline triple-quoted f-string ... with single quotes''' 'Multiline triple-quoted f-string\nwith single quotes' 👇 >>> f"""Multiline triple-quoted f-string ... with double quotes""" 'Multiline triple-quoted f-string\nwith double quotes' Copied!

Up to this point, your f-strings look pretty much the same as regular strings. However, if you create f-strings like those in the examples above, you’ll get complaints from your code linter if you have one.

The remarkable feature of f-strings is that you can embed Python variables or expressions directly inside them. To insert the variable or expression, you must use a replacement field, which you create using a pair of curly braces.

Interpolating Variables Into F-Strings

The variable that you insert in a replacement field is evaluated and converted to its string representation. The result is interpolated into the original string at the replacement field’s location:

Python >>> site = "Real Python" 👇 >>> f"Welcome to {site}!" 'Welcome to Real Python!' Copied!

In this example, you’ve interpolated the site variable into your string. Note that Python treats anything outside the curly braces as a regular string.

Read the full article at https://realpython.com/python-formatted-output/ »

[ 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 ]

At DrupalCon Barcelona 2024, Elise West of SystemSeed presented a session on Human-Centered Design (HCD), explaining its growing relevance in Drupal projects. The session highlighted HCD’s role in aligning development with user needs, making it essential for project managers, developers, and product leads. More insights from SystemSeed's experience will follow.

As I upload photos to various services, I generally resize them as required based on portrait or landscape mode. I used to do that for all the photos in a directory and then pick which ones to use. But, I wanted to do it selectively, open the photos in Gnome Nautilus (Files) application and right click and resize the ones I want.

This week I noticed that I can do that with scripts. Those can be in any given language, the selected files will be passed as command line arguments, or full paths will be there in an environment variable NAUTILUS_SCRIPT_SELECTED_FILE_PATHS joined via newline character.

To add any script to the right click menu, you just need to place them in ~/.local/share/nautilus/scripts/ directory. They will show up in the right click menu for scripts.

Below is the script I am using to reduce image sizes:

#!/usr/bin/env python3 import os import sys import subprocess from PIL import Image # paths = os.environ.get("NAUTILUS_SCRIPT_SELECTED_FILE_PATHS", "").split("\n") paths = sys.argv[1:] for fpath in paths: if fpath.endswith(".jpg") or fpath.endswith(".jpeg"): # Assume that is a photo try: img = Image.open(fpath) # basename = os.path.basename(fpath) basename = fpath name, extension = os.path.splitext(basename) new_name = f"{name}_ac{extension}" w, h = img.size # If w > h then it is a landscape photo if w > h: subprocess.check_call(["/usr/bin/magick", basename, "-resize", "1024x686", new_name]) else: # It is a portrait photo subprocess.check_call(["/usr/bin/magick", basename, "-resize", "686x1024", new_name]) except: # Don't care, continue pass

You can see it in action (I selected the photos and right clicked, but the recording missed that part):

Test your understanding of Python’s tools for string formatting, including f-strings and the .format() method.

Take this quiz after reading our A Guide to Modern Python String Formatting Tools tutorial.

[ 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 ]

In the next release of Dolphin, the search backend (when Baloo indexing is disabled) will be faster and support more file types, by using external projects ripgrep-all and ripgrep to do the search. Merge Request

What are ripgrep and ripgrep-all?

ripgrep is a fast text search tool that uses various optimizations including multi-threading (compared to grep and Dolphin's internal search backend which are single-threaded).

ripgrep-all, quote its homepage, is "ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, etc.".

How to enable it

Install the ripgrep-all package from your distribution's package manager (which should also install ripgrep). Then Dolphin will automatically use it for content search, when Baloo is disabled.

If your distribution doesn't provide ripgrep-all, you can also try installing ripgrep. Then Dolphin will use it for content search, but without the additional file type support.

Limitations

• It only works in content search mode, and when Baloo content indexing is disabled. File name search still uses the internal backend.

• It only works in local directories. When searching in remote directories (e.g. Samba, ssh), the internal search backend is used. Although we can run ripgrep in remote directories through the kio-fuse plugin, testing shows it can be 3 times slower than the internal backend, so it's not used.

• It doesn't work on Windows. Although both ripgrep and ripgrep-all have releases for Windows, I personally don't have Windows experience to integrate them. Merge request to enable it on Windows is welcome.

Customization

You can change the command line with which Dolphin calls the external tools. Copy /usr/share/kio_filenamesearch/kio-filenamesearch-grep to ~/.local/share/kio_filenamesearch/, and modify the script there. The script contains comments on the calling convention between Dolphin and it, and explanations on the command line options.

One option you might want to remove is -j2. It limits the number of threads ripgrep (and ripgrep-all) uses to 2. Using more threads can make the search much slower in hard disks (HDD). I tried to detect HDD automatically, but it's not reliable, so I went with a conservative default. It's still faster than the internal backend, but if you have an SSD, you can remove the option to unlock the full speed of ripgrep.

You can also use a different external tool. (E.g. the silver search (ag). Or a full-text search engine other than Baloo) Just make sure it outputs paths separated by NUL. Usually a -0 option will do that.

More customization

You can even modify the script so that you can specify different external tools in the search string. For example, you can insert the following code before the original code that calls ripgrep-all:

...(line 1-33) --run) if test "$2" = "@git"; then exec sh -c 'git status -s -z|cut -c 4- -z' fi ...

Then if you search for "@git" in a git directory, it will show you changed files.

Future works

There are quite a lot to improve in Dolphin's search (when not using Baloo). The content search should also search in file names. The search string is currently interpreted as a regular expression, but a fuzzy match or shell globbing seems to be a more sensible default (probably with regexp as an option). Hopefully future works will address these issues.

As a Top-rated Drupal Development Company, attending DrupalCon Barcelona for the first time exceeded all of our expectations. The energy of the event was incredible, and it gave us the opportunity to connect with so many people in person. One of the standout moments was the inspiring StarShot initiative, whose marketing strategy makes a compelling case for businesses to consider Drupal as a solution.

Starshot / Drupal CMS Product Strategy

NO CODE website building, built on top of Drupal core itself. So, it will be easily able to beat the other no-code solutions like WIX, SQUARESPACE, and Shopify while still being able to maintain its open-source nature where you still will be able to have full control to customize and override things on your own.

Join Tania Allard, PSF Board Member, and Łukasz Langa, CPython Developer-in-Residence, for ‘Python 3.13 and the Latest Trends: A Developer’s Guide to 2025’, a live stream event hosted by Paul Everitt from JetBrains. Thank to JetBrains for partnering with us on the Python Developers Survey and this event to highlight the current state of Python!

The session will take place tomorrow, October 3, at 5:00 pm CEST (11:00 am EDT). Tania and Łukasz will be discussing the exciting new features in Python 3.13, plans for Python 3.15 and current Python trends gathered from the 2023 Annual Developers Survey. Don't miss this chance to hear directly from the experts behind Python’s development!

Watch the live stream event on YouTube

Don’t forget to enable YouTube notifications for the stream and mark your calendar.

I have adopted uv for a lot of Python development. I'm also a heavy user of direnv, which I like as a tool for setting up project-specific environments.

Much like Hynek describes, I've found uv sync to be fast enough to put into the chdir path for new directories. Here's how I'm doing it.

Direnv Libraries

First, it turns out you can pretty easily define custom direnv functions like the built-in ones (layout python, etc...). You do this by adding functions to ~/.config/direnv/direnvrc or in ~/.config/direnv/lib/ as shell scripts. I use this extensively to make my .envrc files easier to maintain and smaller. Now that I'm using uv here is my default for python:

function use_standard-python() { source_up_if_exists dotenv_if_exists source_env_if_exists .envrc.local use venv uv sync } What does that even mean?

Let me explain each of these commands and why they are there:

• source_up_if_exists -- this direnv stdlib function is here because I often group my projects into directories with common configuration. For example, when working on Chicon 8, I had a top level .envrc that set up the AWS configuration to support deploying Wellington and the Chicon 8 website. This searches up til it finds a .envrc in a higher directory, and uses that. source_up is the noisier, less-adaptable sibling.

• dotenv_if_exists -- this loads .env from the current working directory. 12-factor apps often have environment-driven configuration, and docker compose uses them relatively seamlessly as well. Doing this makes it easier to run commands from my shell that behave like my development environment.

• source_env_if_exists .envrc.local -- sometimes you need more complex functionality in a project than just environment variables. Having this here lets me use .envrc.local for that. This comes after .env because sometimes you want to change those values.

• use venv -- this is a function that activates the project .venv (creating it if needed); I'm old and set in my ways, and I prefer . .venv/bin/activate.fish in my shell to the more newfangled "prefix it with a runner" mode.

• uv sync -- this is a super fast, "install my development and main dependencies" command. This was way, way too slow with pip, pip-tools, poetry, pdm, or hatch, but with uv, I don't mind having this in my .envrc

Using it in a sentence

With this set up in direnv's configuration, all I need in my .envrc file is this:

use standard-python

I've been using this pattern for a while now; it lets me upgrade how I do default Python setups, with project specific settings, easily.

With PyCharm, you now have the support of AI Assistant at your fingertips. You can interact with it right where you do most of your work – in the editor. 

Stuck with an error in your code? Need to add documentation or tests? Just start typing your request on a new line in the editor, just as if you were typing in the AI Assistant chat window. PyCharm will automatically recognize your natural language request and generate a response.  

PyCharm leaves a purple mark in the gutter next to lines changed by AI Assistant so you can easily see what has been updated. 

If you don’t like the initial suggestion, you can generate a new one by pressing Tab. You can also adjust the initial input by clicking on the purple block in the gutter or simply pressing Ctrl+/ or ⌘/.

Want to get assistance with a specific argument? You can narrow the context that AI Assistant uses for its response as much as you want. Just put the caret in the relevant context, type the $ or ? symbol, and start writing. PyCharm will recognize your prompt and take the current context into account for its suggestions. 

The new inline AI assistance works for Python, JavaScript, TypeScript, JSON, and YAML file formats, while the option to narrow the context works only for Python so far.

This feature is available to all AI Assistant subscribers in the second PyCharm 2024.3 EAP build. You can get a free trial version of AI Assistant straight in the IDE: to enable AI Assistant, open a project in PyCharm, click the AI icon on the right-hand toolbar, and follow the instructions that appear.

Download PyCharm 2024.3 EAP

Cédric Krier has found that python-sql does not escape non-Expression for unary operators (like And and Or) which makes any system exposing those vulnerable to an SQL injection attack.

Impact

CVSS v3.0 Base Score: 9.1

• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low
• User Interaction: None
• Scope: Changed
• Confidentiality: High
• Integrity: Low
• Availability: Low

Workaround

There is no known workaround.

Resolution

All affected users should upgrade python-sql to the latest version.

Affected versions: <= 1.5.1
Non affected versions: >= 1.5.2

Reference

• Unary operators does not escape non-Expression (#93) · Issues · Tryton / python-sql · GitLab

Concerns?

Any security concerns should be reported on the bug-tracker at https://bugs.tryton.org/python-sql with the confidential checkbox checked.

2 posts - 2 participants

Read full topic

Microblogging v1.3.0 for Pelican released! Posts should now sort as expected. Thanks @ashwinvis. on PyPI #Microblogging #Pelican Plugins #Releases #Python

This being my first post on the KDE sphere (or any other sphere), it was supposed to be just a touch of contact with the world of blogging. But since time pass by in a blast, let's just summarize how I lived my third one in-person Akademy 2024.

Würzbug. Back to Germany

This year's Akademy happily got me back to Germany, which has become like a second home and a place I like to visit at least once a year (yeah, I missed the Dürüms).

I had bought the D-Ticket, which allowed my to board any public transport immaginable (well, except for ICE trains, but I haven't heard much good about them either) for bare 49€. It brought me some memories back as a student in Dresden, enjoying the same perks with the Semesterticket, just on a regional scope. Thanks to Itinerary and its route planner I was able to make it to Würzburg even an hour earlier than anticipated (less 20min train delay which I've heard it's currently quite a good metric).

After having my hotel booking cancelled last minute due to needed repair works, I had booked an appartment because the hotel prices were a bit over the top. I was really lucky to find that just around the corner I had a bus stop to go to the venue, and also Andy Betts and Richard Wagner as ilustrious neighbors. And one of the best rated Dönner places in the city. Very lucky indeed!

The Talks

It's hard to make a better summary of the Talks days that our very own Promo Team's report, which I agree with on many points.

What I particulary felt on these Akademy's talks was a high focus into the future. Some words were thematically present along most of the talks: story, product, and impact.

The story we as the KDE community want to tell is not just a bunch of code packages that live in an ethereal world to be grabbed by a few enthusiasts or distros, but a full useful product for the end users, an inviting environment for fellow developers, and a reliable asset for manufactures on their very concrete hardware.

There were many reveals and surprises to achieve this goal. Projects that had been incubating for some time, were now made public on this Akademy: the KDE OS Codename Banana by Harald Sitter, the Next Project and design system by Andy Betts and the Union theme engine by Arjen Hiemstra.

Some talks addressed the social and environmental impact of the technology we create. The one that specially got to me was the small story Nicole Teal told at her lightning talk. How a group of kids gave many "older" PCs a new life installing KDE, while learning new skills and making community, felt really true and a spur to continue contributing to FOSS. It really matters.

From the technical talks, I enjoyed "What is color, anyway" by Xaver Hugl, and unfortunately had to miss some other ones (Python and Rust integration with Qt). This is the hardest part, where you cannot just .clone() yourself and attend to two talks at the same time. Maybe I would have learnt to do that if I had attended the Rust presentation? (yeah, sorry bad Rust dad joke)

It was also on Sunday when Aniqa and Carl took me by surprise to agains my will happily answer to a small video interview. Just joking, it was fun. Just preemptively preparing myself for when the final video comes out and I can see what words I did babble :D.

The BoFs

After a very intense weekend of talks and the social event and post-event on Sunday, I took the Monday's morning off to have some rest. In the evening, Andy and Manuel showed me a bit more about the design system they're using and the icon exporter Manuel has been developing to streamline the process between designers and the final product. Amazing stuff!

I also started a draft of this very blog post, which wasn't much successful as you can imagine by its final release date.

The big BoF day for me was mostly Tuesday, where I focussed on the Plasma and the VDG ones, though I missed those on KWin's roadmap and window tiling, due to competing schedules. During the Plasma BoF, we could experiment in real time, the step-by-step process of realeasing the Plasma 6.1.5 version, thanks to Jonathan, our Plasma release manager.

Finally, on Thursday I got to enjoy the brand new Sticker BoF. Besides me not having any stickers on my own to share, and being mostly minimalistic when it comes to decoration, I had a great time and ended up sticking my laptop up and about, including an very limited unit of the Sticker BoF's sticker. Thanks Kieryn for organizing it. Of course, Carl won the sticker's award 😄.

On a more personal level, I regret a bit not having participated more on some of the BOFs. Most of my KDE's contributions this summer have been improvements on very niche aspects: the Weather widget and the tool to preview keyboard layouts (tastenbrett), so I felt a bit "out of the loop" on the more general and pressing matters in Plasma.

The Socials

Where the Akademy really shines is in putting together some hundreds of amazing people with some common interests, that in the end happen to make the best software products and computing ecosystem out there.

It is a real warp of space and time. On the Welcome Event I got to meet Eva Brucherseifer, one of the attendants and founders of the very first Akademys, and also recent joiners to the community I only knew via chat or MR interactions.

When the Biergarten that was booked for the Sunday Social Event did cancel due to a storm warning, I could immediately check two things:

• that the Weather Widget did correctly report the Warnung vor starkem Gewitter
• and that the local organizing team went the extra mile to make the Akademy a success, even against the elements. Beer, pizzas and good people was all required to have an enjoyable evening.

Finally I was really happy to meet again with friends from the previous Akademys and the Plasma Sprint in 2023, sharing opinions on widespread topics, suchs as immovable OSes, ingenuous ways to open a beer bottle, keyboard input methods, or the torture and punishment customs of German cities in medieval times.

Thanks to the organizing team, the speakers, the attendants, the patrons and the whole KDE Community which made possible yet another amazing Akademy!

We’ve just completed an extensive overhaul of our frontend tooling, with Vite and Storybook at the centre. Let’s go over it piece by piece.

by jack.taranto / 2 October 2024

The goal of the overhaul was to modernise all aspects of the build stack, remove legacy dependencies and optimise development processes.

Tooling is split into four pieces: asset building, styleguide, linting and testing.

Asset building for Drupal with Vite

We have always utilised two separate tools to build CSS and JS assets. Until now, this was PostCSS and Rollup, in the past Sass and Webpack have been in the mix. 

With Vite it’s one tool to build both types of assets. To introduce Vite to anyone not already familiar with it, I would say it’s a super fast version of Rollup without the configuration headaches. 

Moving to Vite sped up our development build times and production build times (in CI), simplified our config files and removed a huge number of NPM dependencies.

Vite library mode

A typical Vite build pipeline is most suitable for single-page apps. It involves an index.html file where Vite dynamically adds CSS and JS assets. However, with Drupal, we do not have an index.html file; we have the Drupal libraries system to load assets, with which Vite has no way of communicating.

Luckily, Vite ships with something called Library mode, which is seemingly tailor-made for Drupal assets! Library mode allows us to output all our frontend assets to a single directory, where we can include them in a libraries.yml file or via a Pinto Theme Object.

To use our config, you’ll first need a few dependencies. 

npm i -D vite postcss-preset-env tinyglobby browserslist-to-esbuild

Our vite.config.js looks like this:

import { defineConfig } from 'vite' import { resolve } from 'path' import { globSync } from 'tinyglobby' import browserslist from 'browserslist-to-esbuild' import postcssPresetEnv from 'postcss-preset-env' const entry = globSync(['**/*.entry.js', '**/*.css'], { ignore: [   '**/_*.css',   'node_modules',   'vendor',   'web/sites',   'web/core',   'web/libraries',   '**/contrib',   'web/storybook', ], }) export default defineConfig(({ mode }) => ({ build: {   lib: {     entry,     formats: ['es'],   },   target: browserslist(),   cssCodeSplit: true,   outDir: resolve(import.meta.dirname, './web/libraries/library-name'),   sourcemap: mode === 'development', }, css: {   postcss: {     plugins: [       postcssPresetEnv(),     ],     map: mode === 'development',   }, }, }))

We define entry points as any *.css file and any *.entry.js file. We exclude certain directories, so we aren’t building assets that are included with core or contrib. Additionally, we exclude CSS partials, which use an underscore prefix. This allows us to add asset source files anywhere in our project. They could be added in the theme, a module, or (as we have been doing recently) inside a /components directory in the project root.

The Vite config itself enables library mode using build.lib, passing all source assets through using build.lib.entry and building JS assets using the es format.

build.cssCodeSplit is required when passing CSS files through to build.lib.entry.

build.outDir specifies a folder inside the Drupal libraries directory where all built assets will be sent. Drupal libraries.yml definitions are then updated to include files from this directory.

build.sourcemap will output JS sourcemaps in development mode only.

Finally, we pass through any PostCSS plugins with css.postcss.plugins. Vite includes postcss-import by default, so you do not need to add that. It will also handle resolving to custom directories without including resolve options for postcss-import, meaning you’ll only need to add your specific plugins. In this case, we reduced ours to just postcss-preset-env. Add more as needed!

We also enable CSS sourcemaps with css.postcss.map.

This config allowed us to completely remove the PostCSS config file, PostCSS CLI, Rollup, its config and all Rollup plugins.

The config file above is a starting point—a minimum viable setup you’ll need to build assets using Vite’s library mode. Add to it as you need to, and familiarise yourself with Vite’s documentation.

Using Browerslist with Vite

Vite uses ESBuild to determine the output feature set based on the build.target. For many years now, we have used Browserslist to determine feature sets for both PostCSS and Rollup, and it works really well. We weren’t ready to lose this functionality by moving to Vite.

This is where the browserslist-to-esbuild dependency comes in. We added the following .browserlistrc file to our project root:

> 1% in AU

By calling browserslist() in build.target we get our browser feature set provided by Browserslist instead of ESBuild.

NPM scripts for development mode and production builds

We use NPM scripts for consistent usage of non-standard commands both locally and on CI for production builds.

"scripts": { "dev-vite": "vite build -w -m development", "build-vite": "vite build" },

To watch and build source assets whilst developing locally, we use npm run dev-vite. Unlike Vite’s dev command, this still uses Rollup under the hood (instead of ESBuild), so we miss out on the extreme speed of Vite’s dev mode. However, it’s still very fast—faster than default Rollup. It’s a tradeoff that provides what we need, which is building our assets while we are editing them in a way that works with Drupal. We lose hot reloading, but that’s less important when we have Storybook at our disposal.

Production builds happen on CI using npm run build-vite.

Using Storybook with Drupal

Although we had been using Storybook in our projects for some time now, we hadn’t yet standardised on it or provided a default setup. And with Vite now baked into Storybook, it seemed like an excellent time to provide this.

If you have a spare 15 minutes, I would first suggest checking out Lee Rowland’s lightning talk from Drupal South to see just how fluid a frontend development experience Storybook brings to Drupal.

Storybook is easy to setup using its wizard with:

npx storybook@latest init

It will present you with a few choices. Just make sure you choose HTML and Vite for your project type. When using Vite with Storybook, Storybook provides its necessary config to Vite; however, it will still read your projects vite.config.js file for any additional config. This includes the PostCSS config we setup above and any additional functionality you provide.

Now, install Lee’s Twig plugin. This plugin will allow us to write components using Twig that can be imported into our stories.js files. First, install the plugin:

npm i -D vite-plugin-twig-drupal

Then register the plugin by adding the following lines to the vite.config.js default export:

plugins: [ twig(), ],

See the vite-plugin-twig-drupal documentation for more details, including how to set up Twig namespaces.

Writing stories

To use Twig in Storybook, it’s quite similar to any other framework. Here’s an example story of a card component:

import Component from './card.html.twig' const meta = { component: Component, args: {   title: `<a href="#">Card title</a>`,   description:     'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam eu turpis molestie, dictum est a, mattis tellus. Sed dignissim, metus nec fringilla accumsan, risus sem sollicitudin lacus.', }, } export default meta export const Card = {}

We import the twig file as Component and then add that to the stories meta. We can pass through args, which will show up in the Twig file as variables, and we can use HTML here.

Writing stories is covered in more detail in our front-end nirvana blog post.

NPM scripts for developing with Vite and Storybook at once

Our standard development practice involves building and testing components in Storybook and then integrating them with Drupal using Pinto. To do this, we need to run Storybook and our Vite tooling at once so we have both Storybook dev mode and our built frontend assets available to us.

Running two NPM scripts in parallel can be a pain, so we have implemented concurrently to streamline this approach.

npm i -D concurrently

Then we use the following in our NPM scripts:

{ "scripts": {   "dev": "concurrently -k -n \"VITE,STORYBOOK\" -c \"#636cff,#ff4785\" \"npm run dev-vite\" \"npm run dev-storybook\"",   "build": "concurrently -n \"VITE,STORYBOOK\" -c \"#636cff,#ff4785\" \"npm run build-vite\" \"npm run build-storybook\"",   "dev-storybook": "storybook dev -p 6006 --no-open",   "build-storybook": "storybook build -o web/storybook",   "dev-vite": "vite build -w -m development",   "build-vite": "vite build" },

With npm run dev we get coloured output so we can see which tool is running and what it’s doing. npm run build is used on CI.

Linting with Prettier, Stylelint and ESLint

These three tools have been a staple on our projects for a long time, but with ESLint introducing a new flat configuration method, it seemed like a good time to review the tooling.

First, we’ll need some more dependencies.

npm i -D prettier stylelint stylelint-config-standard eslint@8.57.0 @eslint/js@8.57.0 eslint-config-prettier eslint-config-drupalFormatting source assets with Prettier

We are using Prettier to format both CSS and JS files. With PHPStorm, you can set this to happen on file save. We also have an NPM script to do this on demand and before committing. NPM commands are at the end of this section.

Reducing Stylelint configuration

Past iterations of our Stylelint tooling involved extensive configuration on each project. Using Stylelints latest standard configuration, it sets sensible defaults, which lets us remove most config options. We’re left with the following:

const config = { extends: ['stylelint-config-standard'], rules: {   'custom-property-empty-line-before': null,   'no-descending-specificity': null,   'import-notation': 'string',   'selector-class-pattern': [     '^([a-z])([a-z0-9]+)(-[a-z0-9]+)?(((--)?(__)?)([a-z0-9]+)(-[a-z0-9]+)?)?$',     {       message:         'Expected class selector to be BEM selector matching either .block__element or .block--modifier',     },   ],   'selector-nested-pattern': '^&', }, } export default config

We added a custom rule to ensure project BEM selectors are used.

Like prettier, we also use a .stylelintignore file to exclude core and contrib folders.

Moving to ESLint flat config

The new config format isn’t yet supported by all plugins (there’s a compatibility tool to help with this), but where it is, it’s much simpler.

The following config can be used in conjunction with Prettier.

import js from '@eslint/js' import globals from 'globals' import prettier from 'eslint-config-prettier' import drupal from 'eslint-config-drupal' export default [ js.configs.recommended, prettier, {   languageOptions: {     globals: {       ...globals.browser,       ...globals.node,       ...drupal.globals,       dataLayer: true,       google: true,       once: true,     },   }, }, {   rules: {     'no-console': 'error',     'no-unused-expressions': [       'error',       {         allowShortCircuit: true,         allowTernary: true,       },     ],     'consistent-return': 'warn',     'no-unused-vars': 'off',   }, }, {   ignores: [     'node_modules',     'vendor',     'bin',     'web/core',     'web/sites',     'web/modules/contrib',     'web/themes/contrib',     'web/profiles/contrib',     'web/libraries',     'web/storybook',   ], }, ]

This includes linting for Storybook files and tests as well. Additionally, it ignores core and contrib files.

NPM scripts for linting

We use the following NPM scripts to run our linting commands locally and on CI.

"scripts": { "format": "prettier --write \"**/*.{css,ts,tsx,js,jsx,json}\"", "lint": "npm run lint-prettier && npm run lint-css && npm run lint-js", "lint-prettier": "prettier --check \"**/*.{css,ts,tsx,js,jsx,json}\"", "lint-css": "stylelint \"**/*.css\"", "lint-js": "eslint ." },

These commands work so well because we have excluded all Drupal core and contrib folders using ignore files. 

Testing using Storybook test runner

Storybook test runner provides the boilerplate-free ability to run automated snapshot and accessibility tests on each story in Storybook. Our previous test tooling involved using Jest and Axe to handle this, but we needed to manually write tests for each component. With Storybook test runner, this is handled automatically.

To set it up, first, install some dependencies.

npm i -D @storybook/test-runner axe-playwright

Then create the following test-runner.js file inside your .storybook directory.

import { waitForPageReady } from '@storybook/test-runner' import { injectAxe, checkA11y } from 'axe-playwright' import { expect } from '@storybook/test'; /* * See https://storybook.js.org/docss/writing-tests/test-runner#test-hook-api * to learn more about the test-runner hooks API. */ const config = { async preVisit(page) {   await injectAxe(page) }, async postVisit(page) {   await waitForPageReady(page)   // Automated snapshot testing for each story.   const elementHandler = await page.$('#storybook-root')   const innerHTML = await elementHandler.innerHTML()   expect(innerHTML).toMatchSnapshot()   // Automated accessibility testing for each story.   await checkA11y(page, '#storybook-root', {     detailedReport: true,     detailedReportOptions: {       html: true,     },   }) }, } export default config

This config will loop through all your stories, wait for them to be ready, then snapshot them and run Axe against them. You’ll get great output from the command, so you can see exactly what’s going on.

NPM scripts for testing Storybook locally and on CI

First, install a few more dependencies:

npm i -D http-server wait-on

The following scripts will run the complete Storybook test base and update snapshots as needed.

"scripts": { "test-storybook": "test-storybook", "test-storybook:update": "test-storybook -u", "test-storybook:ci": "concurrently -k -s first -n \"SERVER,TEST\" -c \"magenta,blue\" \"npm run http-server\" \"wait-on tcp:6006 && npm run test-storybook\"", "http-server": "http-server web/storybook -p 6006 --silent" },

To run tests on CI we use http-server to serve the built version of Storybook and wait-on to delay the test run until the server is ready. The concurrently command smooths the output of both these commands.

Wrapping up

See the complete workflow, including all config and ignore files in the pnx-frontend-build-tools-blog repository I've setup for this post.

The repository and this blog post have been designed to provide the necessary pieces so you can implement this workflow on your existing (or new) projects. However, a lot more functionality can be gained, including easily adding support for Typescript, React and Vitest.

Tagged Storybook, Vite

Kraft (Github) is the desktop app making it easy to create offers and invoices quickly and beautifully in small companies. It is targetted to the free desktop and runs on Linux.

This is the release announcement of the new Kraft version 1.2.2. This is a small service release that fixes a few bugs and CI issues.

Right after this release, the branch with significant changes for Kraft 2.0 will be merged to master. These changes will make Kraft ready for sharing documents across private file clouds and with that enable use cases for distributed use via internet, along with other significant feature updates.

Details about the next big release with version number 2.0 can be read on the Github Discussion page.

Any feedback and contribution is highly appreciated.

#649 – OCTOBER 1, 2024
View in Browser »

Python 3.13: Cool New Features for You to Try

In this tutorial, you’ll learn about the new features in Python 3.13. You’ll take a tour of the new REPL and error messages and see how you can try out the experimental free threading and JIT versions of Python 3.13 yourself.
REAL PYTHON

Incremental GC and Pushing Back the 3.13.0 Release

Some last minute performance considerations are delaying the release of Python 3.13 with one of the features being backed out. The new target is next week.
PYTHON.ORG

Debug With pdb and breakpoint()

Python ships with a command-line based debugger called pdb. To set a breakpoint, you call the breakpoint() function in your code. This post introduces you to pdb and debugging from the command-line.
JUHA-MATTI SANTALA

Last Chance to be Part of Snyk’s DevSeccon 2024 Oct 8-9!

Don’t miss out on your chance to register for DevSecCon 2024! From the exciting lineup of 20+ sessions, here’s one that you can’t skip: Ali Diamond, from Hak5: “I’m A Software Engineer, and I Have to Make Bad Security Decisions—why?” Save your spot →
SNYK.IO sponsor

Django Project Ideas

Looking to experiment or build your portfolio? Discover creative Django project ideas for all skill levels, from beginner apps to advanced full-stack projects.
EVGENIA VERBINA

2025 DSF Board Nominations

DJANGO SOFTWARE FOUNDATION

Quiz: Using Python’s pip

REAL PYTHON

Quiz: Python Virtual Environments

REAL PYTHON

Articles & Tutorials Python 3.13 Preview: A Modern REPL

In this tutorial, you’ll explore one of Python 3.13’s new features: a new and modern interactive interpreter, also known as a REPL.
REAL PYTHON

When Should You Upgrade to Python 3.13?

This post talks about the pros and cons of upgrading to Python 3.13 and why you might do it immediately or wait for the first patch release in December.
ITAMAR TURNER-TRAURING

Refactoring Python With Tree-Sitter & Jedi

Jack was toying around with a refactor where he wanted to replace a variable name across a large number of files. His usual tools of grep and sed weren’t sufficient, so he tried tree-sitter instead. Associated HN Discussion.
JACK EVANS

rerankers: A Lightweight Library to Unify Ranking Methods

Information retrieval often uses a two-stage pipeline, where the first stage does a quick pass and the second re-ranks the content. This post talks about re-ranking, the different methods out there, and introduces a Python library to help you out.
BENJAMIN CLAVIE

Counting Sheeps With Contracts in Python

A code contract is a way of specifying how your code is supposed to perform. They can be useful for tests and to generally reduce the number of bugs in your code. This article introduces you to the concept and the dbc library.
LÉO GERMOND

Paying Down Tech Debt: Further Learnings

Technical debt is the accumulation of design decisions that eventually slow teams down. This post talks about two ways to pay it down: using tech debt payments to get into the flow, and what you need before doing a big re-write.
GERGELY OROSZ

Asyncio gather() in the Background

The asyncio.gather() method works as the meeting point for multiple co-routines, but it doesn’t have to be a synchronous call. This post teaches you how to use .gather() in the background.
JASON BROWNLEE

Advanced Python import Techniques

The Python import system is as powerful as it is useful. In this in-depth video course, you’ll learn how to harness this power to improve the structure and maintainability of your code.
REAL PYTHON course

Mentors

Ryan just finished his second round mentoring with the Djangonaut.Space program. This post talks about both how you can help your mentor help you, and how to be a good mentor.
RYAN CHELEY

Customising Object Creation With __new__

The dunder method __new__ is used to customise object creation and is a core stepping stone in understanding metaprogramming in Python.
RODRIGO GIRÃO SERRÃO

Prompting a User for Input

This short post shows you how to prompt your users for input with Python’s built-in input() function.
TREY HUNNER

When and How to Start Coding With Kids

Talk Python interviews Anna-Lena Popkes and they talk about how and when to teach coding to children.
TALK PYTHON podcast

Projects & Code g1: Using Llama-3.1 to Create Reasoning Chains

GITHUB.COM/BKLIEGER-GROQ

DSPy: Framework for Programming Foundation Models

GITHUB.COM/STANFORDNLP

TikTokAutoUploader: Auto Upload and Schedule TikToks

GITHUB.COM/HAZIQ-EXE

tinystatus: Tiny Status Page Generated by a Python Script

GITHUB.COM/HARSXV

django-appointment: Manage Appointment Scheduling

GITHUB.COM/ADAMSPD

Events Weekly Real Python Office Hours Q&A (Virtual)

October 2, 2024
REALPYTHON.COM

PyConZA 2024

October 3 to October 5, 2024
PYCON.ORG

Canberra Python Meetup

October 3, 2024
MEETUP.COM

Sydney Python User Group (SyPy)

October 3, 2024
SYPY.ORG

PyCon ES 2024

October 4 to October 6, 2024
PYCON.ORG

Django Day Copenhagen 2024

October 4 to October 5, 2024
DJANGODAY.DK

PyCon Uganda 2024

October 9 to October 14, 2024
PYCON.ORG

PyCon NL 2024

October 10 to October 11, 2024
PYCON.ORG

Happy Pythoning!
This was PyCoder’s Weekly Issue #649.
View in Browser »

[ Subscribe to 🐍 PyCoder’s Weekly 💌 – Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

Read more

Dries mentioned the comparison towards the Sagrada Familia in the Driesnote in Barcelona and this really resonated with me. Especially after visiting it after Drupalcon. I thought I'd take the comparison a little further, you know, for the fun of it :)

Here we go:

Drupal and the Sagrada FamíliadrupalTuesday, October 1, 2024 - 21:26