Feeds

Hey you're back! 🙂 In the previous post we talked about how to build a custom Drupal theme using Storybook as the design system. We also built a simple component to demonstrate how Storybook, using custom extensions, can understand Twig. In this post, the focus will be on making Drupal aware of those components by connecting Drupal to Storybook.
If you are following along, we will continue where we left off to take advantage of all the prep work we did in the previous post. Topics we will cover in this post include:

1. What is Drupal integration
2. Installing and preparing Drupal for integration
3. Building components in Storybook
4. Building a basic front-end workflow
5. Integrating Drupal with Storybook components

What is Drupal integration?

In the context of Drupal development using the component-driven methodology, Drupal integration means connecting Drupal presenter templates such as node.html.twig, block.html.twig, paragraph.html.twig, etc. to Storybook by mapping Drupal fields to component fields in Storybook. This in turn allows for your Drupal content to be rendered wrapped in the Storybook components.

The advantage of using a design system like Storybook is that you are in full control of the markup when building components, as a result your website is more semantic, accessible, and easier to maintain.

Building more components in Storybook

The title component we built in the previous post may not be enough to demonstrate some of the advanced techniques when integrating components. We will build a larger component to put these techniques in practice. The component we will build is called Card and it looks like this:

When building components, I like to take inventory of the different parts that make up the components I'm building. The card image above shows three parts: An image, a title, and teaser text. Each of these parts translates into fields when I am defining the data structure for the component or building the entity in Drupal.

Building the Card component

• Open the Drupal site in your code editor and within your code editor navigate to the storybook theme (web/themes/custom/storybook)
• Create two new directories inside components called 01-atoms and 02-molecules
• Inside 02-molecules create a new directory called card
• Inside the card directory add the following four files:
  • card.css: component's styles
  • card.twig: component's markup and logic
  • card.stories.jsx: Storybook's story
  • card.yml: component's demo data
• Add the following code snippet to card.yml:

--- modifier: '' image: <img src="https://source.unsplash.com/cHRDevKFDBw/640x360" alt="Palm trees near city buildings" /> title: level: 2 modifier: '' text: 'Tours & Experiences' url: 'https://mariohernandez.io' teaser: 'Step inside for a tour. We offer a variety of tours and experiences to explore the building’s architecture, take you backstage, and uncover the best food and drink. Tours are offered in different languages and for different levels of mobility.'

• Add the following to card.twig to provide the markup and logic for the card:

{{ attach_library('storybook/card') }} <article class="card{{ modifier ? ' ' ~ modifier }}{{- attributes ? ' ' ~ attributes.class -}}" {{- attributes ? attributes|without(class) -}}> {% if image %} <div class="card__image"> <figure> {{ image }} </figure> </div> {% endif %} <div class="card__content"> {% if title %} {% include "@atoms/title/title.twig" with { 'level': title.level, 'modifier': title.modifier, 'text': title.text, 'url': title.url, } only %} {% endif %} {% if teaser %} <p class="card__teaser">{{ teaser }}</p> {% endif %} </div> </article>

Code snippet for building card

• Copy and paste these styles into card.css.

• Finally, let's create the Storybook card story by adding the following to card.stories.jsx:

import parse from 'html-react-parser'; import card from './card.twig'; import data from './card.yml'; import './card.css'; const component = { title: 'Molecules/Card', }; export const Card = { render: (args) => parse(card(args)), args: { ...data }, }; export default component;

Let's go over a few things regarding the code above:

• The data structure in card.yml reflects the data structure and type we will use in Drupal.
  • The image field uses the entire <img> element rather than just using the image src and alt attributes. The reason for this is so when we get to Drupal, we can use Drupal's full image entity. This is a good practice for caching purposes.
• card.twig reuses the title component we created in the previous post. Rather than build a title from scratch for the Card and repeat the code we already wrote, reusing the existing components keeps us DRY.
• card.stories.jsx in the Storybook story for the Card, notice how the code in this file is very similar to the code in the title.stories.jsx. Even with complex components, when we port them into Storybook as stories, most times the code will be similar as what you see above because Storybook is simply parsing whatever is in .twig and .yml files. There are exceptions when the React code may have extra parameters or logic which typically happens when we're building stories variations. Maybe a topic for a different blog post. 😉

Before we preview the Card, some updates are needed

You may have noticed in card.twig we used the namespace @atoms when nesting the title component. This namespace does not exist, and we need to create it now. In addition, we need to move the title component into the 01-atoms directory:

• In your code editor or command line (whichever is easier), move the title directory into the 01-atoms directory
• In your editor, open title.stories.jsx and change the line
  title: 'Components/Title' to title: 'Atoms/Title'. This will display the title component within the Atoms category in Storybook's sidebar.
• Rather than have you make individual changes to vite.config.js, let's replace/overwrite all its content with the following:

/* eslint-disable */ import { defineConfig } from 'vite' import yml from '@modyfi/vite-plugin-yaml'; import twig from 'vite-plugin-twig-drupal'; import { join } from 'node:path' export default defineConfig({ root: 'src', publicDir: 'public', build: { emptyOutDir: true, outDir: '../dist', rollupOptions: { input: { 'reset': './src/css/reset.css', 'styles': './src/css/styles.css', 'card': './src/components/02-molecules/card/card.css', }, output: { assetFileNames: 'css/[name].css', }, }, sourcemap: true, }, plugins: [ twig({ namespaces: { atoms: join(__dirname, './src/components/01-atoms'), molecules: join(__dirname, './src/components/02-molecules'), }, }), // Allows Storybook to read data from YAML files. yml(), ], })

Let's go over some of the most noticeable updates inside vite.config.js:

• We have defined a few things to improve the functionality of our Vite project, starting with using src as our app root directory and public for publicDir. This helps the app understand the project structure in a relative manner.

• Next, we defined a Build task which provides the app with defaults for things like where should it compiled code to (i.e. /dist), and rollupOptions for instructing the app which stylesheets to compile and what to call them.

• As part of the rollupOptions we also defined two stylesheets for global styles (reset.css and styles.css). We'll create these next.

  Important This is as basic as it gets for a build workflow and in no way would I recommend this be your front-end build workflow. When working on bigger projects with more components, it is best to define a more robust and dynamic workflow that provides automation for all the repetitive tasks performed on a typical front-end project.

• Under the Plugins section, we have defined two new namespaces, @atoms and @molecules, each of which points to specific path within our components directory. These are the namespaces Storybook understands when nesting components. You can have as many namespaces as needed.

Adding global styles

• Inside storybook/src, create a new directory called css
• Inside the css directory, add two new files, reset.css and styles.css
• Here are the styles for reset.css and styles.css. Please copy them and paste them into each of the stylesheets.
• Now for Storybook to use reset.css and styles.css, we need to update /.storybook/preview.js by adding these two imports directly after the current imports, around line 4.

import '../dist/css/reset.css'; import '../dist/css/styles.css'; Previewing the Card in Storybook Remember, you need NodeJS v20 or higher as well as NVM installed on your machine

• In your command line, navigate to the storybook directory and run:

nvm install npm install npm run build npm run storybook

A quick note about the commands above:

• nvm install and npm install are typically only done once in your app. These commands will first install and use the node version specified in .nvmrc, and will install all the required node packages found in package.json. If you happen to be workign on another project that may use a different version of node, when you comeback to the Storybook project you will need to run nvm use in order to resume using the right node version.
• npm run build is usually only ran when you have made configuration changes to the project or are introducing new files.
• npm run storybook is the command you will use all the time when you want to run Storybook.

After Storybook launches, you should see two story categories in Storybook's sidebar, Atoms and Molecules. The title component should be under Atoms and the Card under Molecules. See below:

Installing Drupal and setting up the Storybook theme

We have completed all the prep work in Storybook and our attention now will be all in Drupal. In the previous post all the work we did was in a standalone project which did not require Drupal to run. In this post, we need a Drupal site to be able to do the integration with Storybook. If you are following along and already have a Drupal 10 site ready, you can skip the first step below.

1. Build a basic Drupal 10 website (I recommend using DDEV).
2. Add the storybook theme to your website. If you completed the excercise in the previous post, you can copy the theme you built into your site's /themes/custom/ directory, Otherwise, you can clone the previous post repo into the same location so it becomes your theme. After this your theme's path should be themes/custom/storybook.
3. No need to enable the theme just yet, we'll come back to the theme shortly.
4. Finally, create a new Article post that includes a title, body content and an image. We'll use this article later in the process.

Creating Drupal namespaces and adding Libraries

Earlier we created namespaces for Storybook, now we will do the same but this time for Drupal. It is best if the namesapces' names between Storybook and Drupal match for consistency. In addition, we will create Drupal libraries to allow Drupal to use the CSS we've written.

• Install and enable the Components module
• Add the following namespaces at the end of storybook.info.yml (mind your indentation):

components: namespaces: atoms: src/components/01-atoms molecules: src/components/02-molecules

• Replace all content in storybook.libraries.yml with the following:

global: version: VERSION css: base: dist/css/reset.css: {} dist/css/styles.css: {} card: css: component: dist/css/card.css: {}

• Let's go over the changes to both, storybook.info.yml and storybook.libraries.yml files:

  • Using the Components module we created two namespaces: @atoms and @molecules. Each namespace is associated with a specific path to the corresponding components. This is important because Drupal by default only looks for Twig templates inside the /templates directory and without the Components module and the namespaces it would not know to look for our component's Twig templates inside the components directory.
  • Then we created two Drupal libraries: global and card. The Global library includes two CSS stylesheets (reset.css and styles.css), which handle base styles in our theme. the Card library includes the styles we wrote for the Card component. If you noticed, when we created the Card component, the first line inside card.twig is a Twig attach library statement. Basically card.twig is expecting a Drupal library called card.

Turn Twig debugging on

All the pieces are in place to Integrate the Card component so Drupal can use it to render article nodes when viewed in teaser view mode.

• The first thing we need to do to begin the integration process is to determine which Twig template Drupal uses to render article nodes in teaser view mode. One easy way to do this is by turning Twig debugging on. This used to be a complex configuration but starting with Drupal 10.1 you can now do it directly in Drupal's UI:

  • While logged in with admin access, navigate to /admin/config/development/settings on your browser. This will bring up the Development settings page.
  • Check all the boxes on this page and click Save settings. This will enable Twig debugging and disable caching.
  • Now navigate to /admin/config/development/performance so we can turn CSS and JS aggregation off.
  • Under Bandwidth optimization cleared the two boxes for CSS and Javascript aggregation then click on Save configuration.
  • Lastly, click the Clear all caches button. This will ensure any CSS or JS we write will be available without having to clear caches.

• With Twig debugging on, go to the homepage where the Article we created should be displayed in teaser mode. If you right-click on any part of the article and select inspect from the context menu, you will see in detail all the templates Drupal is using to render the content on the current page. See example below.

  Note I am using a new basic Drupal site with Olivero as the default theme. If your homepage does not display Article nodes in teaser view mode, you could create a simple Drupal view to list Article nodes in teaser view mode to follow along.

In the example above, we see a list of templates that start with node...*. These are called template suggestions and are the names Drupal is suggesting we can assign our custom templates. The higher the template appears on the list, the more specific it is to the piece of content being rendered. For example, changes made to node.html.twig would affect ALL nodes throughout the site, whereas changes made to node--1--teaser.html.twig will only affect the first node created on the site but only when it's viewed in teaser view mode.

Notice I marked the template name Drupal is using to render the Article node. We know this is the template because it has an X before the template name.

In addition, I also marked the template path. As you can see the current template is located in core/themes/olivero/templates/content/node--teaser.html.twig.

And finally, I marked examples of attributes Drupal is injecting in the markup. These attributes may not always be useful but it is a good practice to ensure they are available even when we are writing custom markup for our components.

Create a template suggestion

By looking at the path of the template in the code inspector, we can see that the original template being used is located inside the Olivero core theme. The debugging screenshot above shows a pretty extensive list of templates suggestions, and based on our requirements, copying the file node--teaser.html.twig makes sense since we are going to be working with a node in teaser view mode.

• Copy /core/themes/olivero/templates/content/node--teaser.html.twig into your theme's /storybook/templates/content/. Create the directory if it does not exist.
• Now rename the newly copied template to node--article--teaser.html.twig.
• Clear Drupal's cache since we are introducing a new Twig template.

As you can see, by renaming the template node--article--teaser (one of the names listed as a suggestion), we are indicating that any changes we make to this template will only affect nodes of type Article which are displayed in Teaser view mode. So whenever an Article node is displayed, if it is in teaser view mode, it will use the Card component to render it.

The template has a lot of information that may or may not be needed when integrating it with Storybook. If you recall, the Card component we built was made up of three parts: an image, a title, and teaser text. Each of those are Drupal fields and these are the only fields we care about when integrating. Whenever when I copy a template from Drupal core or a module into my theme, I like to keep the comments on the template untouched. This is helpful in case I need to reference any variables or elements of the template.

The actual integration ...Finally

1. Delete everything from the newly copied template except the comments and the classes array variable
2. At the bottom of what is left in the template add the following code snippet:

{% set render_content = content|render %} {% set article_title = { 'level': 2, 'modifier': 'card__title', 'text': label, 'url': url, } %} {% include '@molecules/card/card.twig' with { 'attributes': attributes.addClass(classes), 'image': content.field_image, 'title': article_title, 'teaser': content.body, } only %}

• We set a variable with content|render as its value. The only purpose for this variable is to make Drupal aware of the entire content array for caching purposes. More info here.
• Next, we setup a variable called article_title which we structured the same way as data inside card.yml. Having similar data structures between Drupal and our components provides many advantages during the integration process.
  • Notice how for the text and url properties we are using Drupal specific variables (label and url), accordingly. If you look in the comments in node--article--teaser.html.twig you will see these two variables.
• We are using a Twig include statement with the @molecules namespace to nest the Card component into the node template. The same way we nested the Title component into the Card.
• We mapped Drupal's attributes into the component's attributes placeholder so Drupal can inject any attributes such as CSS classes, IDs, Data attributes, etc. into the component.
• Finally, we mapped the image, title and teaser fields from Drupal to the component's equivalent fields.
• Save the changes to the template and clear Drupal's cache.

Enable the Storybook theme

Before we forget, let's enable the Storybook theme an also make it your default theme, otherwise all the work we are doing will not be visible since we are currently using Olivero as the default theme. Clear caches after this is done.

Previewing the Article node as a Card

Integration is done and we switched our default theme to Storybook. After clearing caches if you reload the homepage you should be able to see the Article node you wrote but this time displayed as a card. See below:

• If you right-click on the article and select Inspect, you will notice the following:
  • Drupal is now using node--article--teaser.html.twig. This is the template we created.
  • The template path is now themes/custom/storybook/src/templates/content/.
  • You will also notice that the article is using the custom markup we wrote for the Card component which is more semantic, accessible, but in addition to this, the <article> tag is also inheriting several other attributes that were provided by Drupal through its Attributes variable. See below:

If your card's image size or aspect ratio does not look as the one in Storybook, this is probably due to the image style being used in the Article Teaser view mode. You can address this by:

• Going to the Manage display tab of the Article's Teaser view mode (/admin/structure/types/manage/article/display/teaser).
• Changing the image style for the Image field for one that may work better for your image.
• Preview the article again on the homepage to see if this looks better.

In closing

This is only a small example of how to build a simple component in Storybook using Twig and then integrate it with Drupal, so content is rendered in a more semantic and accessible manner. There are many more advantages of implementing a system like this. I hope this was helpful and see the potential of a component-driven environment using Storybook. Thanks for visiting.

Download the code For a full copy of the code base which includes the work in this and the previous post, clone or download the repo and switch to the card branch. The main branch only includes the previous post code.

Download the code

We have released version 7.1.1 of Texinfo, the GNU documentation format. This is a minor bug-fix release.

It's available via a mirror (xz is much smaller than gz, but gz is available too just in case):

http://ftpmirror.gnu.org/texinfo/texinfo-7.1.1.tar.xz
http://ftpmirror.gnu.org/texinfo/texinfo-7.1.1.tar.gz

Please send any comments to bug-texinfo@gnu.org.

Full announcement:

https://lists.gnu.org/archive/html/bug-texinfo/2024-09/msg00041.html

In this episode we're talking about importing part of a package into another part of the same package.

We'll look at: `from . import module` and `from .module import something`

and also:  `import package` to access the external API from with the package.

Why would we use `import package` if `from . import api` would work fine?

 Learn pytest

• pytest is the number one test framework for Python.
• Learn the basics super fast with Hello, pytest!
• Then later you can become a pytest expert with The Complete pytest Course
• Both courses are at courses.pythontest.com

<p>In this episode we're talking about importing part of a package into another part of the same package.</p><p><br></p><p>We'll look at: `from . import module` and `from .module import something`</p><p>and also:  `import package` to access the external API from with the package.</p><p><br></p><p>Why would we use `import package` if `from . import api` would work fine?</p> <br><p><strong> Learn pytest</strong></p><ul><li>pytest is the number one test framework for Python.</li><li>Learn the basics super fast with <a href="https://courses.pythontest.com/hello-pytest">Hello, pytest!</a></li><li>Then later you can become a pytest expert with <a href="https://courses.pythontest.com/the-complete-pytest-course">The Complete pytest Course</a></li><li>Both courses are at <a href="https://courses.pythontest.com/">courses.pythontest.com</a></li></ul>

Testing the feed in English and check If it's going to Debian Planet.

Is Python pass by reference or pass by value? This question intrigues every Python programmer coming from a C or Java background. In this tutorial, you will get its answer and learn the meaning of “pass by reference” and “pass by value” along with their difference in Python. Python Pass by Reference vs Pass by […]

The post Pass by Reference vs Pass by Value in Python appeared first on TechBeamers.

Hi there!
A big joint release today. Mostly security fixes but we also have the final release candidate of 3.13 so let’s start with that!

Python 3.13.0RC2

Final opportunity to test and find any show-stopper bugs before we bless and release 3.13.0 final on October 1st.

Get it here: Python Release Python 3.13.0rc2 | Python.org

Call to action

We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.13 compatibilities during this phase, and where necessary publish Python 3.13 wheels on PyPI to be ready for the final release of 3.13.0. Any binary wheels built against Python 3.13.0rc2 will work with future versions of Python 3.13. As always, report any issues to the Python bug tracker.

Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is not recommended for production environments.

Core developers: time to work on documentation now

• Are all your changes properly documented?
• Are they mentioned in What’s New?
• Did you notice other changes you know of to have insufficient documentation?

As a reminder, until the final release of 3.13.0, the 3.13 branch is set up so that the Release Manager (@thomas) has to merge the changes. Please add him (@Yhg1s on GitHub) to any changes you think should go into 3.13.0. At this point, unless something critical comes up, it should really be documentation only. Other changes (including tests) will be pushed to 3.13.1.

New features in Python 3.13

• A new and improved interactive interpreter, based on PyPy’s, featuring multi-line editing and color support, as well as colorized exception tracebacks.
• An experimental free-threaded build mode, which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well.
• A preliminary, experimental JIT, providing the ground work for significant performance improvements.
• The locals() builtin function (and its C equivalent) now has well-defined semantics when mutating the returned mapping, which allows debuggers to operate more consistently.
• The (cyclic) garbage collector is now incremental, which should mean shorter pauses for collection in programs with a lot of objects.
• A modified version of mimalloc is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode.
• Docstrings now have their leading indentation stripped, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.)
• The dbm module has a new dbm.sqlite3 backend that is used by default when creating new files.
• The minimum supported macOS version was changed from 10.9 to 10.13 (High Sierra). Older macOS versions will not be supported going forward.
• WASI is now a Tier 2 supported platform. Emscripten is no longer an officially supported platform (but Pyodide continues to support Emscripten).
• iOS is now a Tier 3 supported platform, with Android on the way as well.

Python 3.12.6

This is an expedited release for 3.12 due to security content. The schedule returns back to regular programming in October.

One notable change for macOS users: as mentioned in the previous release of 3.12, this release drops support for macOS versions 10.9 through 10.12. Versions of macOS older than 10.13 haven’t been supported by Apple since 2019, and maintaining support for them has become too difficult. (All versions of Python 3.13 have already dropped support for them.)

Get it here: Python Release Python 3.12.6 | Python.org

92 commits.

Python 3.11.10

Python 3.11 joins the elite club of security-only versions with no binary installers.

Get it here: Python Release Python 3.11.10 | Python.org

28 commits.

Python 3.10.15

Get it here: Python Release Python 3.10.15 | Python.org

24 commits.

Python 3.9.20

Get it here: Python Release Python 3.9.20 | Python.org

22 commits.

Python 3.8.20

Python 3.8 is very close to End of Life (see the Release Schedule). Will this be the last release of 3.8 ever? We’ll see… but now I think I jinxed it.

Get it here: Python Release Python 3.8.20 | Python.org

22 commits.

Security content in today’s releases

• gh-123678 and gh-116741: Upgrade bundled libexpat to 2.6.3 to fix CVE-2024-28757, CVE-2024-45490, CVE-2024-45491 and CVE-2024-45492.
• gh-118486: os.mkdir() on Windows now accepts mode of 0o700 to restrict the new directory to the current user. This fixes CVE-2024-4030 affecting tempfile.mkdtemp() in scenarios where the base temporary directory is more permissive than the default.
• gh-123067: Fix quadratic complexity in parsing "-quoted cookie values with backslashes by http.cookies. Fixes CVE-2024-7592.
• gh-113171: Fixed various false positives and false negatives in IPv4Address.is_private, IPv4Address.is_global, IPv6Address.is_private, IPv6Address.is_global. Fixes CVE-2024-4032.
• gh-67693: Fix urllib.parse.urlunparse() and urllib.parse.urlunsplit() for URIs with path starting with multiple slashes and no authority. Fixes CVE-2015-2104.
• gh-121957: Fixed missing audit events around interactive use of Python, now also properly firing for python -i, as well as for python -m asyncio. The event in question is cpython.run_stdin.
• gh-122133: Authenticate the socket connection for the socket.socketpair() fallback on platforms where AF_UNIX is not available like Windows.
• gh-121285: Remove backtracking from tarfile header parsing for hdrcharset, PAX, and GNU sparse headers. That’s CVE-2024-6232.
• gh-114572: ssl.SSLContext.cert_store_stats() and ssl.SSLContext.get_ca_certs() now correctly lock access to the certificate store, when the ssl.SSLContext is shared across multiple threads.
• gh-102988: email.utils.getaddresses() and email.utils.parseaddr() now return ('', '') 2-tuples in more situations where invalid email addresses are encountered instead of potentially inaccurate values. Add optional strict parameter to these two functions: use strict=False to get the old behavior, accept malformed inputs. getattr(email.utils, 'supports_strict_parsing', False) can be use to check if the strict paramater is available. This improves the CVE-2023-27043 fix.
• gh-123270: Sanitize names in zipfile.Path to avoid infinite loops (gh-122905) without breaking contents using legitimate characters. That’s CVE-2024-8088.
• gh-121650: email headers with embedded newlines are now quoted on output. The generator will now refuse to serialize (write) headers that are unsafely folded or delimited; see verify_generated_headers. That’s CVE-2024-6923.
• gh-119690: Fixes data type confusion in audit events raised by _winapi.CreateFile and _winapi.CreateNamedPipe.
• gh-116773: Fix instances of <_overlapped.Overlapped object at 0xXXX> still has pending operation at deallocation, the process may crash.
• gh-112275: A deadlock involving pystate.c’s HEAD_LOCK in posixmodule.c at fork is now fixed.

Stay safe and upgrade!

Upgrading is highly recommended to all users of affected versions.

Thank you for your support

Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.

–
Łukasz Langa @ambv
on behalf of your friendly release team,

Ned Deily @nad
Steve Dower @steve.dower
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv
Thomas Wouters @thomas

 

 

Focus

This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• duck: add indicators (1 2)
• Debian wiki pages: PortsDocs/New, Rust

Issues

• Regressions in adequate (1 2 3 4)

Review

• Debian publicity: reviewed Debian birthday post

Administration

• Debian servers: contributed to a review of current Debian Partners

Communication

• Respond to queries from Debian users and contributors on IRC

Sponsors

All work was done on a volunteer basis.

Whilst speaking with Dave Liddament last week, I remembered a slide I've seen in some of his previous presentations, such as Effective Code Review.

On the slide is a graph that shows the amount of time needed to fix a bug at different stages of the development lifecycle.

Fixing a bug is the quickest and simplest when writing code.

It's harder when being code reviewed or QA or client tested, more so when it's being released, and the most difficult and expensive once it's in the maintenance phase.

Once it's live in the production environment, there's additional cleanup work to do which adds to the time and cost, and potentially damages your reputation.

The sooner you can find a bug, the better.

This is where tools such as automated testing, static analysis and CI pipelines shine and make it easier for you to find and fix potential bugs sooner.

The KDE community has charted its course for the coming years, focusing on three interconnected paths that converge on a single point: community. These paths aim to improve user experience, support developers, and foster community growth.

Streamlined Application Development Experience

This goal focuses on improving the application development process. By making it easier for developers to create applications, KDE hopes to attract more contributors and deliver better software for both first-party and third-party applications. A notable task within this goal is enhancing the experience of building KDE apps with languages beyond C++, such as Rust or Python.

Champions: Nicolas Fella and Nate Graham

We care about your Input

KDE has a diverse users base with unique input needs: artists using complex monitor and drawing tablet setups; gamers with controllers, fancy mice, and handhelds; users requiring accessibility features or using a language optimally types with complex input methods; students with laptops, 2-in-1s, and tablets — and more! While KDE has made significant progress in supporting these diverse sources of input over the years, there are still gaps to be addressed. This goal aims to close those gaps and deliver a truly seamless input experience for everyone.

Champions: Gernot Schiller, Jakob Petsovits and Joshua Goins

KDE Needs You! 🫵

KDE’s growth depends on new contributors, but a lack of fresh involvement in key projects like Plasma, Kdenlive, Krita, GCompris, and others is a concern. This goal focuses on formalizing and enhancing recruitment processes, not just for individuals but also for institutions. Ensuring that bringing in new talent becomes a continuous and community-wide priority, vital for KDE's long-term sustainability.

Champions: Aniqa Khokhar, Johnny Jazeix and Paul Brown

Join us!

Your voice, your code, and your ideas are what will shape the KDE of tomorrow — whether you're a user, developer, or contributor. Let’s go on this journey together and make these goals a reality!

Join the Matrix room and keep an eye on the website for the latest KDE Goals updates.

Python programs are created in code editors, and can be run using system command prompt.

Table of contents

1. The Python REPL
2. Definitions: program, script, command-line, editor
3. Creating a Python program in a code editor
4. Running our Python program
5. Printing to see program output
6. Python programs are not launched from the REPL
7. Different operating systems
8. Python scripts are run from the command prompt or terminal

The Python REPL

This is the Python REPL, also known as the Interactive Python Interpreter:

>>>

How can I tell it's the Python REPL?

Well, the prompt shows three greater than signs (>>>), which indicates that we're in the Python REPL.

Typing all of your code in the Python REPL is pretty limiting.

Our code disappears right after we've typed it. Also, if we'd like someone to be able to import our code as a module, they can't.

Definitions: program, script, command-line, editor

Let's make a Python program.

Read the full article: https://www.pythonmorsels.com/creating-python-programs/

We are thrilled to announce that Djangonaut Space, a mentorship program, is open for applicants for our next cohort!

Djangonaut Space is holding a third session this year! This session will start on October 14th, 2024. We are accepting applications until September 14th, 2024. More details can be found in the website.

Djangonaut Space is a free, 8-week group mentoring program where individuals will work self-paced in a semi-structured learning environment. It seeks to help members of the community who wish to level up their current Django code contributions and potentially take on leadership roles in Django in the future.

“I signed up for this program with the goal of starting my journey as a contributor, but I ended up gaining so much more. In this community, I found incredible people who not only guide you toward solutions but also encourage and celebrate every achievement along the way.” - Raffaella, Djangonaut

If you have questions, they are holding an AMA session on Zoom next week. See their social media account for more details:

• Twitter/X
• Mastodon

How does cta1href sound to you? Gibberish, right? :D
Jesse “jessebaker” Baker pointed out that Experience Builder (XB) in its current state was subjecting its users to such nonsense! Fortunately, thanks to every Single Directory Component (SDC) specifying a title for each prop, we were able to automatically generate the much more readable CTA 1 link — thanks to foundations Ben “bnjmnm” Mullins did in #3461422 from 3 weeks prior.

Utkarsh “utkarsh_33” and Omkar “omkar-pd” Deshpande eliminated an extraneous “preview” request from the client, hence improving performance (as well as sanity).

Ben & Jesse made XB’s Cypress end-to-end tests leap massively ahead (especially compared to Drupal core’s use of Nightwatch), by introducing cypress-terminal-report. The resulting test failure output on GitLab CI makes it far easier to figure out where something is going wrong: a big productivity boost!

Two weeks ago I alluded to it, and now it finally happened: after months of getting basic infrastructure off the ground, we now finally were able to Kyle “ctrladel” Einecker’s set of representative SDCs that Lauri approved, Ivan “finnsky” Berdinsky and I reviewed, and Ted “tedbow” Bowman pushed across the finish line.
(Not everything Kyle proposed landed, because XB and the SDC subsystem do not yet have all the capabilities needed for some of the SDCs he wrote — see the follow-up if you’re interested.)

The very first component tree rendered in Experience Builder: both slots of this ‘two column’ SDC contain other SDCs!
Issue #3446722, image by me.

Some of the people working full-time on XB are doing so using DDEV. And running end-to-end tests that use WebDriver with both the test runner and the system under test living in a Docker container turns out to be quite challenging! Besides us, we know that many (most?) in the community use a DDEV-based development environment, and we’d love to welcome as many contributors as possible. Not being able to run the most important tests of all then is of course quite a problem.
That’s why Travis “traviscarden” Carden had been diligently (he actually joined a few weeks ago!) working on making that painless. The result: the ddev-drupal-xb-dev DDEV add-on — once installed, running (and seeing!) the XB end-to-end tests requires only ddev xb-cypress-open :)

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Feliksas “f.mazeikis” Mazeikis is back full-time on XB, and he’s started working on the super important #3463999: Auto-create/update Component config entities for all discovered SDCs that meet XB’s minimum criteria. It’s a critical piece in making Lauri’s product vision come to life: it will ensure that any SDC that we’re confident will work in XB becomes available automatically.1 While working on that, he discovered that there was a pretty big oversight in the StorablePropShape work I landed two weeks ago: in some places Drupal core does not distinguish between “instance settings” and “storage settings” at all (and nor did the code I landed then), but in some places it actually does. Felix was running into that now, thanks to config validation, and so he fixed that.

Many of the things that happened this week were on the “enablement” side of things. Nonetheless, the XB UI also made progress:

1. Harumi “hooroomoo” Jang and Jesse landed the updated “insert” UX and hierarchy view, based on the updated design.
2. But, most importantly, nicely rounding out this post by combining “enablement” and improved UX: Bálint “balintbrews” Kléri implemented error boundaries. In principle, you should never see these, but we all occasionally have internet connection issues. At those times, Bálint’s “Try again” addition works beautifully :)
   (And as a bonus it accelerates debugging failing server responses!)

Error boundaries with a friendly ‘Try again’.
Issue #3461431, image by Bálint.

Thanks to Travis for reviewing this!

Week 14 was August 12–18, 2024.

1. At this early stage, it’ll happen indiscriminately. Later, we’ll ensure that on production environments no new SDCs will be made available to the Content Creator without explicit approval by the Site Builder. See the first steps towards auditability of the available XB components if you’re interested in this aspect. ↩︎

• Drupal
• Acquia
• Experience Builder

• The very first component tree rendered in Experience Builder: both slots of this 'two column' SDC contain other SDCs!
• Error boundaries with a friendly 'Try again'.

In an exclusive interview with The DropTimes, Vincenzo Gambino, a Drupal Architect and Senior React Developer, shares his journey from Palermo to London, exploring how Drupal shaped his career. From working on high-traffic projects for Cambridge University to co-authoring "Jumpstart Jamstack Development", Vincenzo discusses Drupal's evolution, its role in headless architectures, and the future of open-source technologies. With over 12 years of experience, he offers insights into Drupal's flexibility, security, and performance, as well as its adaptability to modern web development trends.

We’re excited to announce the September 2024 release of the Python and Jupyter extensions for Visual Studio Code!

This release includes the following announcements:

• Django unit test support
• Go to definition from inlay hints with Pylance

If you’re interested, you can check the full list of improvements in our changelogs for the Python, Jupyter and Pylance extensions.

Django unit test support

We are excited to announce support for one of our most requested features: you can now discover and run Django unit tests through the Test Explorer!

In order to enable this feature, you will need to add a MANAGE_PY_PATH environment variable, pointing to your Django application’s manage.py file. To do so, you can follow these steps:

1. Set "python.testing.unittestEnabled": true, in your settings.json file.
2. Add MANAGE_PY_PATH as an environment variable:
   1. Create a .env file at the root of your project.
   2. Add MANAGE_PY_PATH='<path-to-manage.py>' to the .env file, replacing <path-to-manage.py> with the path to your application’s manage.py file.

      Tip: You can copy the path by right clicking on the file in the Explorer view and selecting Copy Path.

3. Add Django test arguments to "python.testing.unittestArgs": [] in the settings.json file as needed, and remove any arguments that are not compatible with Django.

Note: By default, the Python extension looks for and loads .env files at the project root. If your .env file is not at the project root or you are using VS Code variable substitution, add "python.envFile": "${workspaceFolder}/<path-to-.env>" to your settings.json file, so the Python extension can load the environment variables in this file when running and discovering tests. See our Python environment variables docs for more information on environment variables.

Navigate to the Testing view, and select the Refresh Tests button to have your Django tests displayed!

For troubleshooting tips, please see our Django testing docs. As you explore this newly added feature, please provide feedback and report any issues in our vscode-python repo or by using the Python: Report Issue command.

Go to definition from inlay hints with Pylance

When enabling inlay hints with Pylance, you can now more conveniently navigate to a type’s definition through Ctrl+Click or Cmd+Click when hovering over it.

Other Changes and Enhancements

We have also added small enhancements and fixed issues requested by users that should improve your experience working with Python and Jupyter Notebooks in Visual Studio Code. Some notable changes include:

• You can now access the VS Code Native REPL for Python from the Command Palette (Ctrl/Cmd + Shift + P) using Python: Start Native REPL(@vscode-python#23727)
• VS Code Native REPL for Python now starts at the project folder (@vscode-python#23821)
• Strings are now normalized when sending commands to the VS Code Native REPL (@vscode-python#23743)
• You can now restart the debugger when debugging tests through the debug control widget (@vscode-python#23752)

Call for Community Feedback

As we are planning and prioritizing future work, we value your feedback! Below are a few issues we would love feedback on:

• Design proposal for test coverage in (@vscode-python#22827)

Try out these new improvements by downloading the Python extension and the Jupyter extension from the Marketplace, or install them directly from the extensions view in Visual Studio Code (Ctrl + Shift + X or ⌘ + ⇧ + X). You can learn more about Python support in Visual Studio Code in the documentation. If you run into any problems or have suggestions, please file an issue on the Python VS Code GitHub page.

The post Python in Visual Studio Code – September 2024 Release appeared first on Python.

Are you interested in practicing your Python skills while learning how to solve astrophysics and astronomy problems? Christopher Trudeau is back on the show this week, bringing another batch of PyCoder's Weekly articles and projects.

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

I've got some big news.

On my way to Akademy, looking forward to meeting people there. Even though I’m traveling with spotty Internet access for now, let’s not loose good habits. Here is my web review for the week 2024-36.

The Internet Archive just lost its appeal over ebook lending - The Verge

Tags: tech, copyright, law, library

This is really bad news… Clearly the publishers cartel would try to outlaw libraries if they were invented today.

https://www.theverge.com/2024/9/4/24235958/internet-archive-loses-appeal-ebook-lending

In Leak, Facebook Partner Brags About Listening to Your Phone’s Microphone to Serve Ads for Stuff You Mention

Tags: tech, privacy, surveillance, advertisement

There, now this seems like a real thing… your phone recording you while you’re not aware for advertisement purposes. Nice surveillance apparatus. Thanks but no thanks.

https://futurism.com/the-byte/facebook-partner-phones-listening-microphone

Why A.I. Isn’t Going to Make Art

Tags: tech, ai, machine-learning, gpt, art, learning, cognition

An excellent essay about generative AI and art. Goes deep in the topic and explains very well how you can hardly make art with those tools. It’s just too remote from how they work. I also particularly like the distinction between skill and intelligence. Indeed, we can make highly skilled but not intelligent systems using this technology.

https://www.newyorker.com/culture/the-weekend-essay/why-ai-isnt-going-to-make-art

Challenging The Myths of Generative AI

Tags: tech, ai, machine-learning, gpt, criticism

Does a good job listing the main myths the marketing around generative AI is built on. Don’t fall for the marketing, exert critical thinking and rely on real properties of those systems.

https://www.techpolicy.press/challenging-the-myths-of-generative-ai/

Is Linux collapsing under its own weight? On Rust for Linux

Tags: tech, linux, rust, kernel, foss, politics

Interesting analysis. For sure the Rust for Linux drama tells something about the Linux kernel community and its complicated social norms.

https://sporks.space/2024/09/05/is-linux-collapsing-under-its-own-weight-on-rust-for-linux/

Rust for Linux revisited

Tags: tech, linux, rust, kernel, politics, foss

Politics in the Linux kernel can indeed be tough. The alternative path proposed to the Rust-for-Linux team is indeed an interesting one, it could bear interesting results quickly.

https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html

LSP: the good, the bad, and the ugly

Tags: tech, semantic, programming, protocols, language

Interesting view about the LSP specification, where it shines, and where it falls short.

https://www.michaelpj.com/blog/2024/09/03/lsp-good-bad-ugly.html

Python Programmers’ Experience

Tags: tech, python, community, data-visualization

Indeed this is a much better visualization. It shows quite well how the Python programmers pool is growing.

https://two-wrongs.com/python-programmers-experience

OAuth from First Principles

Tags: tech, oauth, security

Nice post explaining the basics of OAuth. If you wonder why the flow seems so convoluted, this article is for you.

https://stack-auth.com/blog/oauth-from-first-principles

Things I Wished More Developers Knew About Databases

Tags: tech, databases

Lots of things to keep in mind when dealing with databases. This is a nice list of “must know” for developers, false assumptions are widespread (and I fall in some of those traps myself from time to time).

https://rakyll.medium.com/things-i-wished-more-developers-knew-about-databases-2d0178464f78

The Latency/Throughput Tradeoff: Why Fast Services Are Slow And Vice Versa

Tags: tech, performance, latency

An old article but a good reminder: you have to choose between latency and throughput, you can’t have both in the same system.

https://blog.danslimmon.com/2019/02/26/the-latency-throughput-tradeoff-why-fast-services-are-slow-and-vice-versa/

The impact of memory safety on sandboxing · Alex Gaynor

Tags: tech, security, safety, memory, sandbox

Interesting point. As the memory safety of our APIs will increase, can we reduce the amount of sandboxing we need? This will never remove completely the need if only for logic bugs, but surely we could become more strategic about it.

https://alexgaynor.net/2024/aug/30/impact-of-memory-safety-on-sandboxing/

LazyFS: A FUSE Filesystem which can be used to simulate data loss on unsynced writes

Tags: tech, tests, storage

That sounds like a very interesting tool to simulate and test potential data loss scenarios. This is generally a bit difficult to do, should make it easier.

https://github.com/dsrhaslab/lazyfs

Greppability is an underrated code metric

Tags: tech, programming, craftsmanship

Good set of advices on naming variables, types, etc. Indeed this makes things easier to find in code bases.

https://morizbuesing.com/blog/greppability-code-metric/

Reasons to write design docs

Tags: tech, architecture, design, documentation, communication

Very good article. I wish I’d see more organisations writing such design documents. They help a lot, and that allows to have a way to track changes in the design. To me it’s part of the minimal set of documentation you’d want on any non trivial project.

https://ntietz.com/blog/reasons-to-write-design-docs/

Differing Values In A Team Are Costly

Tags: tech, values, organization, team, management

Aligning people with differing core values in a team is indeed necessary but difficult. It can kill your project for small teams, for larger teams you will likely need to think your organization keeping the misalignment in mind.

https://rtpg.co/2024/08/31/cost-of-a-values-gap/

Twelve rules for job applications and interviews

Tags: tech, hiring, interviews

Good set of advices. I wish more people applying for a job would follow them.

https://vurt.org/articles/twelve-rules/

Is My Blue Your Blue?

Tags: colors, cognition, funny

One of those essentials questions in life now has some form of answer. Where is the blue/green boundary for you?

https://ismy.blue/

Bye for now!

In this episode, we continued working with the Kamal deploy tool. Last time, we build a demo image. With this session, we created a Digital Ocean Droplet (i.e., VM) and deployed to that. Along the journey, we learned a lot about how Kamal operates.

In my 15+ years in the Drupal community, I've been fortunate to have been able to lead a few Drupal-related groups and I sometimes find myself in the position of encouraging other leaders - who are experiencing burnout - on how to gracefully step down from leadership positions after multiple years of service.

When I say "groups," I'm talking about things like:

• Drupal event organizers
• Drupal module/theme/project maintainers
• Drupal initiative leaders
• Drupal working group leaders

It seems counter-intuitive to encourage folks to step away from things they have successfully led, but I'm very fond of the concept that the true sign of a healthy organization is a successful change in leadership to make way for new perspectives, insights and ultimately fresh ideas.

In this article, I'll share some of my thoughts on my experiences in doing this exact thing with two prominent Drupal groups: the Florida DrupalCamp organizing team and the Drupal Community Working Group.

Being a leader in the Drupal community comes with responsibilities, but it also comes with prestige. Leaders tend to be more visible and therefore able to promote themselves or their organizations to their advantage. 

Background

My leadership positions were gratifying, and I was still committed to them, but from my perspective, I had remained in them longer than was good for the organization or for me. But, I had an incredibly strong drive to ensure that I left the group in better shape than when I joined.

I was one of the original organizers of Florida DrupalCamp and ended up being the leader of the team by attrition. The other original organizers became less involved as the years went on, and I ended up taking on more-and-more duties. There wasn't a breaking point, but I realized that things weren't heading in the right direction.

For the Drupal Community Working Group, I was added to an incredibly strong team dealing with really difficult issues, but without a structured plan for length of terms or any other way to protect the mental health of its members.

In both cases, I was incredibly proud of the work we were doing, but didn't see a clear path to roll over leave either team in a healthy manner. 

The good news

From my perspective, there are two things people need to do in order to successfully step down from leadership positions:

1. Train your replacement(s).
2. Codify roles and responsibilities.

The bad news

Neither of these two steps can be done overnight.

The detailsTrain your replacement(s)

You (yes, you) need to make a concerted effort to identify, approach, and ask someone (or in many cases, "someones") to fill your role when you leave. Once you find these magical people, then it is (again) up to you to train them in what you do. It is important that you communicate not only the work involved in being a leader, but also the advantages that come with the role.

For Florida DrupalCamp, I made it known well in advance that I was looking to step down as its leader (but willing to stay on in a lesser capacity). I knew it would be good for the event and community if there was new leadership. I told the other organizers as well as mentioning it during the event's opening and closing sessions. Most importantly, I did it early and spoke about it often. This directly led to several people stepping up.

This will likely be a time-consuming process, but it will make the team stronger. It will force you to document and organize what you do, and just the act of explaining it to someone else will allow you and your replacement to identify things that need to be documented as well as possible opportunities for efficiency gains.

Assume that you'll need to be training your replacement for at least a few months, but the timeframe really depends on the cadence of your team's primary tasks. 

Codify roles and responsibilities

This was especially important for the Drupal Community Working Group, as prior to my joining the group, there weren't any guidelines for length of term, how the leader was selected, and how to step away gracefully. Under the leadership of George DeMet, our team implemented all of these, and more. Both George and I led the team for more years than was probably healthy for either of us, but by the time I stepped away, there were clear guidelines for all of these things (with a significant focus on the mentally draining Conflict Resolution Team).

For less formal teams, this could be as simple as a wiki page or an issue in the project's queue with what you and the other leaders do, what your boundaries are, and what your plans for the future are. This can be especially effective when someone makes a request of you that you feel is above-and-beyond - it is nice to have a document that you could point to where roles and responsibilities are detailed.

I'll admit that I skipped this step when stepping down as leader of the Florida DrupalCamp organizing team, as I wasn't leaving the team completely - I just stepped down into a lesser role but was always available to the new leaders for questions and advice. 

Getting started

There are many Drupal groups that have informal leadership roles, with many leaders who definitely feel that if they leave, then the group will fall. Clearly, this is not a healthy situation.

In this case, my advice is this: start by writing up a document/drupal.org page that describes what you do as leader and share it with the rest of the group. Then, be proactive and find a potential replacement and start the training process using the document as a guide. 

No replacement

It should be obvious that the "finding your replacement" step requires a human being other than yourself being involved. But what happens if you can't find someone…

This situation can be stressful and heartbreaking at the same time, but I have a strong opinion on this - if you find yourself in this situation, then maybe it is time for the team to be disbanded or go dormant. If there's not enough interest in the community to keep the group alive, it's not your responsibility to sacrifice your time/money/mental-health. My advice is to write up your thoughts, announce your intentions (and time frame) and post it to all members of the group. This can be done in a way that sets up a future leader to use the codified roles and responsibilities as a framework to get things moving again. In a way, you're still training your replacement - just not in realtime.

Will there be people who are disappointed and/or angry with you for "abandoning" the group? Perhaps, but you'll need to do your best to ignore those folks and focus on setting up the next leader for success.

I would suggest that you keep things simple and focus on the main goal of always leaving the group in a positive manner, setting up future leaders for success.

Thanks to AmyJune Hineline, Adam Varn, Mike Herchel, George DeMet, and Gwendolyn Anello (who reviews pretty much everything I write) for reviewing this post prior to publication.