Feeds

A strange fact recently came into my purview – many users and developers don’t know what Open Source is.

Some time ago, there was a controversy regarding the Floorp web browser (a fork of Firefox) going closed source.

The cause for this was that some company forked Floorp and made a browser based on it. I’ll not comment on the irony that the author of a fork of a project complained that someone forked his project.

Obviously, this triggered a storm of negative reactions on quite a few platforms where fans of Free Software / Open Source software hang out.

The developer responded that this is just temporary, and that the browser will soon be Open Source again. After a while, the repositories became public again and all was fine.

The developer said that Floorp is again Open Source, the angry mob said good, the Floorp browser is again Open Source. And every discussion about Floorp got a plethora of comments that people should stop complaining, that Floorp is Open Source, and that the previous situation was just a misunderstanding.

Open Source

The term Open Source is well defined at opensource.org.

Making the source code of a program publicly available is not enough for something to be Open Source. Having an army of people saying that something is Open Source, is not enough for something to be Open Source.

If a license that the code is published under doesn’t conform to the criteria published on opensource.org, a program is not Open Source. A program whose license contains the following sentence, is, by definition, not Open Source:

You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, or distributing the Software for use with commercial products.

– Floorp private components/LICENSE

This is strangely worded as it looks like you can not use the Floorp web browser to access, for example, a work e-mail account as that would be using it for commercial purposes. This is likely not what the license author intended – the intent of the license is to disallow creating commercial products by forking Floorp.

While it is a valid desire of the author not to have somebody else profit from his work, it is the thing that makes the Floorp web browser not Open Source.

You can call it ‘source available’, you can call it ‘fair code’ but you can not call it Open Source.

Redefining Open Source

This blog post should have been written when the Floorp thing happened, but I thought this is just a random incident not worth the extra attention.

It seems I was wrong. It is something that people should start paying attention to.

A lot of people – developers and users alike, intentionally or not – misuse the term Open Source, and some of them like FUTO even go that far to redefine it and create their own incompatible The Open Source Definition that will suit their own purpose.

Open Source Confusion Cases

Now, the main purpose of this post isn’t for me to let off some steam, but to share a great project started by Dan Brown of attempting to find and list all projects which claim to be Open Source while their licenses say otherwise.

It can be found on his Github account.

You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing. -->

This year, as part of our annual election process, the Python Software Foundation Board is offering three bylaws changes for our Members to vote on. These changes are all centered on our membership experience: making it simpler to qualify as a Member for Python-related volunteer work, making it easier to vote, and allowing the Board more options to keep our membership safe and enforce the Code of Conduct.

Voting Members will be asked to vote on these items during the July Board of Directors election. If the majority of voting members vote in favor of any of the changes, those changes will be incorporated into the bylaws and go into immediate effect.

We're sharing these changes with you today as an opportunity to understand why these changes are being proposed, and to give you an opportunity to ask questions of the Board before you vote, either by emailing psf-elections@pyfound.org or membership-wg@pyfound.org, or by responding to the thread on the PSF discussions site.

The text of the changes are available from the following links, all of which show visual representations of additions and deletions to our canonical bylaws repository:

• Change 1: Merging Contributing and Managing member classes
• Change 2: Simplifying the voter affirmation process by treating past voting activity as intent to continue voting
• Change 3: Allow for removal of Fellows by a Board vote in response to Code of Conduct violations, removing the need for a vote of the membership

The Board has carefully considered these changes and strongly encourages all Members to vote in favor of them. The rest of this post explains the changes, and why we're putting them to our Voting Members.

Change 1: Merging Contributing and Managing member classes

Since 2017, when we adopted our current membership model, we've had four classes of membership: Supporting (recognition for being a monetary donor), Managing (recognition for volunteer work in the PSF or in community events), Contributing (recognition for volunteer work on open source software), and Fellow (recognition of long-term service to the mission of the PSF).

For almost as long as our membership options have existed, there's been confusion about the distinction between Managing and Contributing members. Both require 5 hours a month of volunteer service, but the distinction between community work and work on software is increasingly out of step with how our community thinks about contributing.

In the future, we want community members to qualify for PSF membership by participating and giving back to the community, either through donating, through volunteer work, or in recognition of long service, without distinguishing between code contributions and non-code contributions.

With this proposed bylaws change, we would merge the Managing and Contributing membership classes. All Managing Members would become Contributing Members, and we would no longer have a Managing Member class. Further, this change would explicitly allow for works of authorship (including documentation, books, or blogs) beyond software to count as volunteer work, provided those works are openly licensed.

We think this would significantly simplify the membership categories, reduce confusion, and make it easier for volunteers who both run events and write code to decide which membership class best applies to them.

Change 2: Simplifying the voter affirmation process by treating past voting activity as intent to continue voting

Our bylaws (section 4.2) require every Member to affirm their intention to vote in an election before they can be issued a ballot. This is intended to ensure that our election reaches a quorum (i.e. one third of ballots issued are actually used to vote), and is therefore valid by our bylaws. Due to technical limitations, we only started requiring this affirmation in practice last year. Since then, we've received feedback that the affirmation process has unintentionally excluded some people who had intended to vote.

It is the Board's intention that we make it as easy as possible to vote in our elections, however, we must balance legal obligations that require us to maintain a quorum in our elections.

This bylaws change would allow us to treat any member who voted in the immediately previous year's election as having affirmed their intention to vote. The Board believes that voting in a PSF election is a good indicator that a member is likely to vote again, and including them in the quorum calculation is unlikely to put our quorum at risk.

While there may be technical limitations to us implementing this change, the change is necessary to allow the Foundation to alter the affirmation procedure at all. It is the Board's intention that this change would be implemented for the 2025 election should the Bylaws change be accepted by the membership during the 2024 election.

Change 3: Allow for removal of Fellows by a Board vote in response to Code of Conduct violations, removing the need for a vote of the membership

Currently PSF Fellows are awarded membership for life, as a reward for exceptional service to the mission of the Foundation. There are deliberately very few ways to remove a Fellow from the membership.

If a Fellow were found to have violated the Foundation's Code of Conduct in a way that warranted termination of their membership, currently the only way to remove them would be to put their removal to a vote of all Voting Members (per section 4.15 of our Bylaws). We believe that requiring a vote of the membership to remove a Code of Conduct violator from our community would subject members of the community --- including people directly impacted by that violator's behavior --- to undue distress.

On the other hand, we believe there is significant legal risk that could arise from Code of Conduct violators known to the PSF using their status as a PSF Fellow to enhance their reputation. In cases where the Foundation needs to act in order to continue being able to serve the Python community effectively, we currently have no choice but to name a known Code of Conduct violator as part of a vote put to the membership.

In practice, this requirement limits our ability to effectively enforce our Code of Conduct. This is a disservice to our community.

This proposed change gives the Board, by a majority vote, the ability to terminate the membership of a Fellow as a consequence of breaching any written policy of the Foundation, specifically including our Code of Conduct. This change would allow the Board to act in cases where there is a clear need for a problematic community member to no longer be affiliated with the Foundation, without further perpetuating the trauma caused by that community member's actions.

Adapted from: https://www.sitback.com.au/insights/article/working-with-javascript-in-d...

As far as I understand it, community initiatives exist because enough people say they’re interested and start working towards the initiative’s goals.

So I thought I would try starting an initiative to solve a problem I see pop up fairly regularly:

• https://www.drupal.org/project/drupal/issues/2873160
• https://www.drupal.org/project/drupal/issues/3198417
• https://drupal.slack.com/archives/C1BMUQ9U6/p1709942944844569
• https://drupal.slack.com/archives/C392CHBEW/p1686752209783039?thread_ts=1686733842.704469&cid=C392CHBEW
• and so on.

Basically: why isn’t there a standard way to install javascript dependencies?

Some modules have tried asset-packagist, but there are myriad problems with that:

• https://drupal.slack.com/archives/C1BMUQ9U6/p1709966024383969?thread_ts=1709942944.844569&cid=C1BMUQ9U6
• https://drupal.slack.com/archives/C392CHBEW/p1709810122839269

I had a whinge about it in #australia-nz: https://drupal.slack.com/archives/C45SW3FLM/p1712295645835869 and took up larowlan’s generous offer to try to get a new initiative this off the ground.

He introduced me to Théodore (@nod_) the frontend framework manager and we three had a short discussion around suitable directions to take. This initiative would not be happening without their help and guidance, thank you so much Lee and Théodore 🙇‍♂️

We explored the idea of using import-maps to let the browser handle module imports and agreed that the cascading downloads would be an unacceptable performance burden on non-admin pages.

The result of that meeting was the idea of trying out publishing Drupal modules on npm, or at least an npm-like repository, since @larowlan mentioned that GitLab can provide one. I got started and wrote some scripts for gathering package names and putting them in a central package.json to be downloaded by npm/yarn/whatever.

Then @larowlan pointed out https://github.com/php-forge/foxy which I had seen, but didn’t really understand the power of. What I didn’t understand was that you could define a package.json file inside a composer package, make a couple of tweaks to composer.json and without publishing any kind of npm package, foxy would find it and treat it like one.

Cue a couple of weeks of messing around with foxy, composer and vite, and I have created a working prototype for compiling multiple Drupal modules (including custom modules if desired) in a project, and routing the library system to the new entry points:

https://github.com/darvanen/drupal-js

It requires a few things:

Any module that wants to opt in:

• Adds php-forge/foxy to require or require-dev in composer.json.

• Adds a module-name.foxy.yml file to represent the library state when using foxy.

Site builders:

• Have one or more modules that use foxy in their project

• Require and enable drupal/foxy

• Add a provided vite.config.js to their project (could this be done by the foxy module?)

• Set up a way to run vite build (or their own implementation):

  • post-install/update commands

  • pipeline?

  • manually?

—

This is where you come in

The prototype is just a starting point. I want us to come together to define a new way of working with JavaScript in Drupal that everyone can and will want to use, similar to how drupal-composer/drupal-project pioneered effective usage of composer and was eventually adopted by core. I intend to keep working on this but I want it to be driven by the community, hence the initiative.

Things you can do right now:

• Spread the word, recruit more people to the initiative, especially if they maintain a module with JS dependencies.

• Try out the prototype and give feedback - no change is too big to explore.

• Join the #frontend-bundler-initiative channel to chat about ways forward - bikeshedding is welcome here, we used to call that brainstorming ;)

• If you have a module with JS dependencies: speak up to have your module included in the prototype, or make a PR.

• Contribute to the foxy module to get it to import css/image/asset dependencies from the vite manifest

So what do you say, are you in?- come join me in the channel!

Transition your Drupal 7 site to Drupal 10 with ease using the automated migration approach. This latest article from our comprehensive migration guide walks you through configuring the Drupal 10 site, enabling migration modules, and utilizing the Migrate Drupal UI for a smooth transition. Are you ready?

Read more mauricio Thu, 06/13/2024 - 06:37

For some time now, Debian has been discussing a possible enhancement to the way that Debian packages are uploaded to the archive. The basic idea is to allow a package upload to be triggered by pushing a signed tag, with some structured metadata, to Salsa, the instance of GitLab that Debian provides for packaging repositories. This would allow Debian package maintainers to use a more typical Git-first workflow, where releases are triggered by Git tags and the release artifacts are built in a clean CI environment, while still enforcing the existing Debian rules about who is allowed to upload packages.

As part of that effort, I recently completed a detailed security review of the tag2upload design. I sent it to debian-vote as part of the ongoing discussion, but have also posted it at the link above to give it a more permanent home.

This security review may be revised based on the discussion if people point out things that I missed.

In this episode, we welcome Will Vincent to the Python Show Podcast. Will has written several books on Django.

We chatted about all things Django and Python. Specifically, we covered the following topics:

• Favorite Python packages

• Podcasts

• Content creation

• Book writing

• Why Django versus another web framework

• AI and writing

• and more!

Links

• Follow Will on Mastodon

• Check out Will’s work on GitHub

• Learn Django with Will

• Will Vincent’s personal website

• Django News newsletter

• Django Chat podcast

• django-microframework

As promised in the last post, I have now orphaned the Pagure Debian package. Here’s the full text I posted on the BTS:

After several years, I finally decided to orphan pagure :-(.

I haven’t been using it as my personal forge anymore, and unfortunately upstream development slowed down quite a bit after the main author and maintainer stopped contributing regularly to the project. But that is not to say that upstream is dead; they are still working towards preparing the next release.

Pagure is a big package with several components and an extensive list of build dependencies (and an even bigger testsuite which I never managed to make fully work on Debian). It is not for the faint of heart, and most of the time is usually spent fixing its (build) dependencies so that it doesn’t get removed from testing.

If I may, I would like to leave some suggestions for a future maintainer.

• I never had the time to write dep8 tests, mainly because setting up the software is not trivial. It would be great if the package had more Debian-centric testing.

• Speaking of the hurdles to setting up Pagure, I believe the package installation could be made a bit more automated using debconf. I don’t see a way to fully automate it (look at d/README.Debian), but there is certainly room for improvement.

I also left a brief TODO list inside d/README.source; feel free to tackle any item there!

I wish the next maintainer can have as much fun with the package as I did when I first made it for Debian!

Thank you,

That’s it. It was while it lasted, but I needed to feel myself unburdened so that I don’t have that constant feeling of “I should be properly maintaining this package…”.

If you feel like you’d like to give it a try at maintaining Pagure, now is the time!

n this session, we will explore how to use Python to enhance your AI projects with:

PyCon US 2024 as Security Developer-in-Residence About • Blog • Newsletter • Links PyCon US 2024 as Security Developer-in-Residence

Published 2024-06-13 by Seth Larson
Reading time: minutes

This critical role would not be possible without funding from the Alpha-Omega project. Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem!

This was my first PyCon US as the Security Developer-in-Residence. I accepted the offer shortly after PyCon US 2023, where Deb Nicholson provided an exciting cliffhanger that the PSF was close to making a hiring decision for the role during the PSF update.

The timing of my hiring to coincide with PyCon US is quite the unique opportunity, it means I get to share all the things we've been able to accomplish together in the past year all-together in person. This also means I get to share the road ahead and learn from many people I don't get to see on a day-to-day, like maintainers of projects large and small, software users at organizations and companies, and users whose work extends beyond software like scientists and industrial control systems operators.

Overall I think this yearly cadence couldn't be better, I'm already looking forward to what I'll be able to share at PyCon US 2025 back in Pittsburgh. As I've said in the past, this role wouldn't be effective without the support of the community, so I want to thank you all for the parts you've played in me being successful.

State of Python Supply Chain Security with Alpha Omega

Alpha Omega is a sponsor of the Python Software Foundation, specifically for my role! Alpha Omega's goal is to "improve global software supply chain security by partnering with open source". I presented alongside Alpha Omega's co-founder Michael Winser. The slides for our presentation are available online.

Alpha Omega uses a two-pronged approach, and it's right there in the name: Alpha and Omega:

• Alpha: Improve the security posture of the most critical projects through staffing.
• Omega: Automated security analysis, metrics, and remediation for wider range of projects.

My role is full-time staffing, so is in the "Alpha" bucket of funding.

Speaking for Alpha Omega on the state of Python supply chain security

For readers of my blog, lots of the content of the presentation is review, but I went over the following accomplishments for the first year of the role:

• Python Software Foundation as a CVE Numbering Authority (and how we helped Linux, curl, and others with a guide).
• Joining Python Security Response Team and working on process
• Working with Python release managers to move the release process to GitHub Actions as an isolated build environment.
• Build reproducibility for the Python release process.
• Software Bill-of-Materials for Python release artifacts.
• Coordinated cross-ecosystem response to libwebp and xz-utils vulnerabilities.
• Tons of community work: PEP reviewer, talks, blogs, and more.

The more interesting part for existing readers is my plans for next year. My plan is to partially shift focus, continue working with Python core developer team of course, but to start making improvements to the wider community of projects using Python as well:

• Enabling Build Provenance and Software Bill-of-Materials for Python packages.
• Adoption of security features, hardening, and best practices for Python packages.
• Special focus on Python packaging tools and workflows.

I finished the talk by describing the unique nature of this role as being flexible and how that's a boon for the rapidly changing space of software supply chain security. This role has a fairly wide scoping, which means that when things come up (like xz-utils and novel social-engineering techniques) it's in this role's scope to think about how to respond for the Python ecosystem.

“Vuln Together”, an open space on vulnerability management

“Got vulns? Let's talk!” -- I co-hosted this open space with GitHub Security champion and CVE board member Madison Oliver. This open space focused on the soft-side of vulnerability management for open source projects: people!

Managing vulnerabilities for open source projects is a non-trivial and effort intensive process, because maintainers need to create and publish a security policy, accept private vulnerability reports, and then know what reporters need, request a CVE ID, know how to estimate severity and write an advisory text, and then how to publish an advisory alongside fixed versions. Phew!

Madison and I pictured holding the open space card for “Vuln Together”

The open space was a forum to discuss difficulties with managing vulnerabilities, answering questions, and pointing folks at resources. We shared recommendations like how maintainers can easily request CVEs from GitHub, enable Private Vulnerability Reporting on GitHub and Confidential Issues on GitLab to make reporting easier, and showed resources like the Guide for Vulnerability Disclosure Process from the OpenSSF Vulnerability Disclosures working group.

The open space was well attended!

Language Summit discussion on CPython security

My bingo space for "xz" was almost immediately filled at PyCon US when I attended the Python Language Summit as the blogger. Release manager and core developer Pablo Galindo Salgado spoke about the Python contribution security model in "the wake of xz-utils backdoor".

The complete language summit blog posts are coming soon to the Python Software Foundation blog (I should know, I authored them!) so if you're interested in this topic you can stay tuned over there. I won't spoil any of the contents of the blog post here, but it was a great discussion all around. Lots of interesting ideas and thoughts from core developers that'll help with figuring process improvements that work for CPython.

Meeting all the people

Mike Fiedler and I were on the stage briefly after Kate Chapman's keynote for a "Meet the Python Software Foundation Security Engineers" segment where we went over our plans for the upcoming year and recommended folks to follow the PSF and PyPI blogs for future updates.

Of course, I got to talk to so many people, too many to name individually. I chatted with the upcoming Release Manager for CPython, Hugo van Kemenade, on some ideas to further improve the CPython release process, specifically around signatures. I chatted with folks from specific sub-ecosystems like Jannis Leidel from Conda and Jazzband, David Lord from Flask, and Jarek Potiuk from Airflow.

Also I handed out stickers! I went through over a hundred, it brought me a lot of joy seeing how much folks liked the derpy snake knight design.

... and beyond!

PyCon US 2024 is the start of conferences this year for me. Shortly after PyCon US it was announced that I will be keynoting PyCon Taiwan in September and also speaking at All Things Open 2024 in Raleigh, North Carolina. If you're attending either of these events get in contact with me (and I promise to bring stickers).

That's all for this post! 👋 If you're interested in more you can read the previous report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.

This work is licensed under CC BY-SA 4.0

Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• elisa: Fix DBus service activation (Commit, fixes bug #487905)
• kcalc: Handle certain expressions correctly (Commit, fixes bug #487614)
• kcolorpicker: Allow picking the screen color with Wayland (Commit, fixes bug #479406)

Distro and app store packagers should update their application packages.

• 24.05 release notes for information on tarballs and known issues.
• Package download wiki page
• 24.05.1 source info page
• 24.05.1 full changelog

For FreeBSD packaging (writing “ports”, as it is called), I usually just build on my host system – either in the actual host, or with poudriere – and call it a day. If it compiles on amd64 then it should work everywhere, right? (After all, “all the world’s a VAX”)

No exciting software engineering here, BTW, just a “here’s how I set up some infrastructure to help me build ports locally in various environments.”

I have recently finally fixed the build of Sayonara, an audio player that I quite like, on amd64. It still fails on i386, though, because of a mismatch between GStreamer integer sizes and host integer sizes, where the code on the Sayonara size assumes they are the same. Gladly, 32-bit code is rarely built and tested these days, but it keeps spamming me with build failures. So I set out to fix it with an i386 VM running FreeBSD 13.2 i386.

What I wanted to do was use the ports tree from my host – it is a git checkout of the upstream FreeBSD ports tree – and clone it into my VM. Then I can do packaging fixes on the host, commit them locally, update the checkout in the VM and test the packaging fixes there, too. I want to keep those commits local so that I don’t pollute the global upstream repo with a ton of “maybe this works” kind of commits. Once I’m done, I can squash it down to one commit and push, fixing the build for once and for all (ha!).

So, serve up a git checkout to some remote. It’s remarkably simple (as long as StackOverflow answers still show up in web search; to guard against future enshittification, these notes are my own copy):

ports$ git daemon --reuseaddr --base-path=. --export-all --verbose

In my ports/ directory, run the simple and insecure git server that comes with it. Export the ports tree. On the receiving (that is, in the VM) side, clone with git:// protocol.

# git clone git://host/ /usr/ports

And voila! That enables a quick turn-around for port fifxes that need to be done on a different machine from where I have my usual ports tree checkout (and my GPG keys, and …).

During his bachelor thesis, Joel Häberli designed and implemented a framework allowing for cashless withdrawals in GNU Taler.

It's been a number of years since we made the switch to DDEV, and have regretted it not once on any given day.

# # Debian / libvirt # # By default, qemu guests network interfaces are created with the # trustGuestRxFilters attribute set to no. This setting blocks # neighbor solicitation and other ipv6 multicast traffic. To enable # neighbor solicitations, modify your interface definition in your # guest definition XML. # For example if you have a guest named bird0 with an interface # definition that looks like this: $ sudo virsh dumpxml bird0 | grep -A7 "type='direct'" <interface type='direct' trustGuestRxFilters='no'> <mac address='52:54:00:AA:BB:CC'/> <source dev='ens2f0np0' mode='bridge'/> <target dev='macvtap3'/> <model type='virtio'/> <alias name='net4'/> <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </interface> # Then use 'virsh edit bird0' change the attribute in the <interface> # element to have the value 'yes' instead: <interface type='direct' trustGuestRxFilters='yes'> <mac address='52:54:00:AA:BB:CC'/> <source dev='ens2f0np0' mode='bridge'/> <target dev='macvtap3'/> <model type='virtio'/> <alias name='net4'/> <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </interface> # If the trustGuestRxFilters attribute is missing, it defaults to no, # so be sure that the attribute exists and that the attribute has a # value of 'yes' Tweet

My Monday started with a pleasant surprise that is only possible in cross-timezone collaborations: Ted “tedbow” 1 had made a huge leap forward on #3450957: Prevent modules from being uninstalled if they provide field types used in an Experience Builder (XB) field, where he’s working on the first aspect where XB’s JSON blobs in the database must be queried.
Drupal 11 requires versions of databases that support JSON querying. Ted rather quickly discovered that JSON querying support is not consistent across different databases … but fortunately Brad “bradjones1 is working on #3343634 to add explicit JSON support to Drupal’s database abstraction layer, which is one of the endeavors sponsored by Pitch-Burgh! So: database nerds, unite!

(That means reviewing Brad’s work in that issue is yet another way of contributing to XB — in addition to helping Single Directory Components (SDC) move forward.)

To ensure we are aware of what works on which database from day one, I updated XB’s CI pipeline to run the test suite against MariaDB+MySQL+PostgreSQL+SQLite.

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!

Later on Monday, Ben “bnjmnm” and Jesse landed an MR that starts to connect the UI that you saw two weeks ago to the back end, and brought it alive: there’s now a tree view to provide a sense of place on the canvas, and much more:

Try it yourself locally if you like, but there’s not much you can do yet.
Install the 0.x branch — the “Experience Builder PoC” toolbar item takes you there!

A day later, the first set of unit tests landed: those for StructuredDataPropExpressions (these express where to retrieve values mapped for SDC props).

On Thursday, Harumi “hooromoo”’s MR to provide the foundations for undo/redo support landed, after the most enthusiastic approval I think I’ve ever seen Lee “larowlan” give! :D

That same day, his colleague Griffyn “griffynh” ran the second asynchronous XB meeting in Drupal Slack (archive on d.o: #3453097), this time with 21 participants of the ~250 people in the #experience-builder channel (~100 more compared to 2 weeks ago).
The most heavily debated topics were the data model/persistence layer and Cypress vs vitest for tests.

By Friday, I managed to finish up the work that I already shared a video of a week prior (see week 3), where a PropSource (which itself uses a PropExpression) can be chosen for each component prop and edited using Drupal’s existing Field Widgets. Crucially, it now includes a fully annotated end-to-end test that verifies the demo in detail:

• an article using an XB field can be created
• expected data is stored for the XB field, with a handful of placed components, and all prop source types: static, dynamic and adapter
• each of these prop sources can be evaluated/resolved to a concrete value to pass into the corresponding SDC prop
• each of the placed components renders into the expected HTML

In other words: it’s making the concrete implementation of #3440578: JSON-based data storage proposal for component-based page building tangible and debuggable in a way that required reading dozens of files previously! 2

Thanks to Ted & Lauri for reviewing this!

1. Forever infamous for his shining sunglasses moment on stage during DrupalCon Pittsburgh — captured it in exquisite detail by Mike “mherchel”! ↩︎

2. Hence it’ll serve as a canary for the data model/storage back-end infrastructure in the short–medium term. ↩︎

• Drupal
• Acquia
• Experience Builder

• The XB UI now gained a tree view in the left sidebar that provides a sense of place, and is kept in sync with the canvas.

One of the main data structures you learn about early in your Python learning journey is the dictionary. Dictionaries are the most common and well-known of Python’s mappings. However, there are other mappings in Python’s standard library and third-party modules. Mappings share common characteristics, and understanding these shared traits will help you use them more effectively.

In this tutorial, you’ll learn about:

• Basic characteristics of a mapping
• Operations that are common to most mappings
• Abstract base classes Mapping and MutableMapping
• User-defined mutable and immutable mappings and how to create them

This tutorial assumes that you’re familiar with Python’s built-in data types, especially dictionaries, and with the basics of object-oriented programming.

Get Your Code: Click here to download the free sample code that you’ll use to learn about mappings in Python.

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

Interactive Quiz

Python Mappings

In this quiz, you'll test your understanding of the basic characteristics and operations of Python mappings. By working through this quiz, you'll revisit the key concepts and techniques of creating a custom mapping.

Understanding the Main Characteristics of Python Mappings

A mapping is a collection that allows you to look up a key and retrieve its value. The keys in mappings can be objects of a broad range of types. However, in most mappings, there are object types that can’t be used as keys, as you’ll learn later in this tutorial.

The previous paragraph described mappings as collections. A collection is an iterable container that has a defined size. However, mappings also have additional features. You’ll explore each of these mapping characteristics with examples from Python’s main mapping types.

The feature that’s most characteristic of mappings is the ability to retrieve a value using a key. You can use a dictionary to demonstrate this operation:

Python >>> points = { ... "Denise": 3, ... "Igor": 2, ... "Sarah": 3, ... "Trevor": 1, ... } >>> points["Sarah"] 3 >>> points["Matt"] Traceback (most recent call last): ... KeyError: 'Matt' Copied!

The dictionary points contains four items, each with a key and a value. You can use the key within the square brackets to fetch the value associated with that key. However, if the key doesn’t exist in the dictionary, the code raises a KeyError.

You can use one of the mappings in the standard-library collections module to assign a default value for keys that aren’t present in the collection. The defaultdict type includes a callable that’s called each time you try to access a key that doesn’t exist. If you want the default value to be zero, you can use a lambda function that returns 0 as the first argument in defaultdict:

Python >>> from collections import defaultdict >>> points_default = defaultdict( ... lambda: 0, ... points, ... ) >>> points_default defaultdict(<function <lambda> at 0x104a95da0>, {'Denise': 3, 'Igor': 2, 'Sarah': 3, 'Trevor': 1}) >>> points_default["Sarah"] 3 >>> points_default["Matt"] 0 >>> points_default defaultdict(<function <lambda> at 0x103e6c700>, {'Denise': 3, 'Igor': 2, 'Sarah': 3, 'Trevor': 1, 'Matt': 0}) Copied!

The defaultdict constructor has two arguments in this example. The first argument is the callable that’s used when a default value is needed. The second argument is the dictionary you created earlier. You can use any valid argument when you call dict() as the second argument in defaultdict() or omit this argument to create an empty defaultdict.

When you access a key that’s missing from the dictionary, the key is added, and the default value is assigned to it. You can also create the same points_default object using the callable int as the first argument since calling int() with no arguments returns 0.

All mappings are also collections, which means they’re iterable containers with a defined length. You can explore these characteristics with another mapping in Python’s standard library, collections.Counter:

Python >>> from collections import Counter >>> letters = Counter("learning python") >>> letters Counter({'n': 3, 'l': 1, 'e': 1, 'a': 1, 'r': 1, 'i': 1, 'g': 1, ' ': 1, 'p': 1, 'y': 1, 't': 1, 'h': 1, 'o': 1}) Copied!

The letters in the string "learning python" are converted into keys in Counter, and the number of occurrences of each letter is used as the value corresponding to each key.

You can confirm that this mapping is iterable, has a defined length, and is a container:

Python >>> for letter in letters: ... print(letter) ... l e a r n i g p y t h o >>> len(letters) 13 >>> "n" in letters True >>> "x" in letters False Copied!

You can use the Counter object letters in a for loop, which confirms it’s iterable. All mappings are iterable. However, the iteration loops through the keys and not the values. You’ll see how to iterate through the values or through both keys and values later in this tutorial.

The built-in len() function returns the number of items in the mapping. This is equal to the number of unique characters in the original string, including the space character. The object is sized since len() returns a value.

You can use the in keyword to confirm which elements are in the mapping. This check alone isn’t sufficient to confirm that the mapping is a container. However, you can also access the object’s .__contains__() special method directly:

Python >>> letters.__contains__("n") True Copied! Read the full article at https://realpython.com/python-mappings/ »

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

2024 Trends: What's New for Drupal Editor Wed, 06/12/2024 - 16:00

People always want to predict the future. They say that is not good, but this doesn't apply to the Drupal 2024 trends. Undoubtedly, Generative Artificial Intelligence will shape tech trends and stimulate further progress in the website development industry.
However, there are other matters worth paying attention to. Mintz, World Wildlife Fund, Chupa Chups, Mattel, and other prominent Drupal websites won’t sit idly by viewing this chaos of innovations and advancements.
Now is the time for unique insights with Golems web development agency about what Drupal 2024 will be like. The more aware you are of prospective game-changing rules, the more up in arms you will act in SEO, marketing, and business growth strategies. Stay tuned to take a sneak peek into the future!

Taking a dive into the deep, dark quagmire of life

Some people have career aspirations from a young age, but for the rest of us, discovering a career-worthy passion, or even learning how to distinguish a job from a career, can take some time. I was nearly ten years into a job in finance (managing insurance/retirement/wealth-building products) when I finally admitted to myself that I couldn’t do it anymore. I felt like I should have a career, not just a job. I wanted to feel proud of the way I spent my days.

Diving in

After some soul-searching, I signed up for a Full-Stack Web Development bootcamp. I was never the kid who tinkered with code or tried to see how my AOL Instant Messenger worked (yes, I was a kid of the 90s) - but I suddenly found myself fascinated with the combination of language, math, and puzzle that was hiding in my browser’s Inspect tool. The bootcamp’s cost made this a risky prospect, but it also made me more likely to commit fully. I can’t say I loved every moment of the grind; working full-time, raising three kids (whom I had adopted just two days into the bootcamp), attending evening classes, keeping up with homework, and maintaining sanity was not always the easiest, but I tend to thrive in chaos. I learned the MERN Stack (MongoDB, Express.js, React, and Node), and after six months I left the bootcamp with one of the highest scores in my class and even higher hopes.

Cue the mass tech layoffs of late 2022, pitting my emerging knowledge against developers with years of experience at tech giants such as the site formerly known as Twitter. My understanding of code was evident, but my ability to explain code was underdeveloped, leaving me flailing in interviews and unable to find anyone willing to take a chance on me. Anyone, that is, until my local Women Who Code chapter posted about Palantir.net’s fellowship program. I applied, spent three months learning Drupal through DrupalEasy's Drupal Career Online program, and started an internship with Palantir.net. That internship turned into a full-time engineering role, and now I’m creating innovative tech and building professional websites from scratch.

Going deep

How could I transition from finance to React/JavaScript to Drupal/PHP in such a short time? Same way I managed to learn French — its proximity to English based on its Latin roots gave me a leg up. Both JavaScript and PHP are Object-Oriented languages, meaning they derive from making real-world objects into code. Object-Oriented Programming, or OOP, is a paradigm that encompasses several coding languages, and since I already had a base in OOP via JavaScript, I mainly needed to learn the syntax of PHP as the concepts were mostly the same. Not only are the languages similar, but the overall folder structure and architecture of both Drupal and React can be set up using the same patterns. I quickly noticed my new Palantiri teammates using the MVC (Model-View-Controller) architecture, which I was already comfortable with.

Another benefit of that MVC architecture is its collaborative nature. By separating sections of the code based on functionality, different people could work simultaneously on building one piece of a site without risking overwriting one another. React most prominently offers collaboration through its separation of interests via Components, delivering an end product to users, while Drupal is set up to not only be collaboratively built, but to allow site builders to delegate content creation, and even site administration, to users.

Surfacing from murky depths

Perhaps the coolest thing I discovered through this journey is the ability to create a site harnessing the powers of both Drupal and React! Drupal’s Content Management System structure creates a powerful backend for React’s simple and extensive front-end library. This just leaves me with the accessibility question - how can we make Drupal a more popular and attainable technology for entry-level developers? According to Statista’s data analytic survey, Drupal ranks 29th among the most-used frameworks among developers worldwide as of 2023. In the same survey, React ranked second only to Node, which is another JavaScript framework.

I think we can find a path for learners of all types, we just need to harness the power of our community to get there. We are not in competition with React or Wordpress or any other framework, Drupal is just another tool that people should have an opportunity to explore at any level. Who knows? Maybe they’ll fall in love like so many others have.

Calm waters

I love the glimmer of awe in people’s eyes now when I tell them I’m a software engineer. I can’t say the path was easy, but I’ve never regretted making the career change, and I never tire of continuing to suck up every ounce of knowledge I can find. I love the curiosity and creativity that I can bring to work with me every day, bouncing from front-end to back-end work, developing brand new technologies, and exploring every little thing that interests me. I’m happy to say I have found my career. 

Culture Drupal People

In this quiz, you’ll test your understanding of the basic characteristics and operations of Python mappings. By working through this quiz, you’ll revisit the key concepts and techniques of creating a custom mapping.

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

Discover why 1xINTERNET swiftly supported the Drupal Starshot Initiative. In this interview by Kazima Abbas, Baddy Sonja Breidert, CEO and Co-Founder, shares the motivations, goals, and impact behind their involvement. Don't miss these valuable insights from a key player in the Drupal community!