Feeds

Join the FSF and friends on Friday, November 15 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

Not entirely sure how people use fluxcd, but I guess most people have something like a flux-system flux kustomization as the root to add more flux kustomizations to their kubernetes cluster. Here all of that is living in a monorepo, and as we're all humans people figure out different ways to break it, which brings the reconciliation of the flux controllers down. Thus we set out to do some pre-flight validations.

Note1: We do not use flux variable substitutions for those root kustomizations, so if you use those, you've to put additional work into the validation and pipe things through flux envsubst.

First Iteration: Just Run kustomize Like Flux Would Do It

With a folder structure where we've a cluster folder with subfolders per cluster, we just run a for loop over all of them:

for CLUSTER in ${CLUSTERS}; do pushd clusters/${CLUSTER} # validate if we can create and build a flux-system like kustomization file kustomize create --autodetect --recursive if ! kustomize build . -o /dev/null 2> error.log; then echo "Error building flux-system kustomization for cluster ${CLUSTER}" cat error.log fi popd done Second Iteration: Make Sure Our Workload Subfolder Have a kustomization.yaml

Next someone figured out that you can delete some yaml files from a workload subfolder, including the kustomization.yaml, but not all of them. That left around a resource definition which lacks some other referenced objects, but is still happily included into the root kustomization by kustomize create and flux, which of course did not work.

Thus we started to catch that as well in our growing for loop:

for CLUSTER in ${CLUSTERS}; do pushd clusters/${CLUSTER} # validate if we can create and build a flux-system like kustomization file kustomize create --autodetect --recursive if ! kustomize build . -o /dev/null 2> error.log; then echo "Error building flux-system kustomization for cluster ${CLUSTER}" cat error.log fi # validate if we always have a kustomization file in folders with yaml files for CLFOLDER in $(find . -type d); do test -f ${CLFOLDER}/kustomization.yaml && continue test -f ${CLFOLDER}/kustomization.yml && continue if [[ $(find ${CLFOLDER} -maxdepth 1 \( -name '*.yaml' -o -name '*.yml' \) -type f|wc -l) != 0 ]]; then echo "Error Cluster ${CLUSTER} folder ${CLFOLDER} lacks a kustomization.yaml" fi done popd done

Note2: I shortened those snippets to the core parts. In our case some things are a bit specific to how we implemented the execution of those checks in GitHub action workflows. Hope that's enough to transport the idea of what to check for.

You’ll often need to format and round a Python float to display the results of your calculations neatly within strings. In earlier versions of Python, this was a messy thing to do because you needed to round your numbers first and then use either string concatenation or the old string formatting technique to do this for you.

Since Python 3.6, the literal string interpolation, more commonly known as a formatted string literal or f-string, allows you to customize the content of your strings in a more readable way.

An f-string is a literal string prefixed with a lowercase or uppercase letter f and contains zero or more replacement fields enclosed within a pair of curly braces {...}. Each field contains an expression that produces a value. You can calculate the field’s content, but you can also use function calls or even variables.

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

In 2004, I was living in London, and decided it was time I had my own little virtual private server somewhere online. As a Debian developer since the start of 2000, it had to be Debian, and it still is… This was before “cloud” as we know it today. Virtual Private Servers (VPS) was a … Continue reading "My own little server"

DrupalCamp Berlin 2024 united 150+ Drupal enthusiasts, showcasing AI innovations, inspiring talks, and Dries Buytaert’s vision for the new “Drupal CMS.” From Splash Awards to collaboration highlights, dive into the full recap of this dynamic event!

Another year, another Drupal Camp, and I'm once again delighted by the community, its great atmosphere, and all the things showcased in the talks, informal meetings, hallways, and social events. The motto "Come for the software, stay for the community" remains as relevant as ever. This year, I noticed quite a few new faces. During the closing session, there was a raffle just for first-time attendees at Drupal Camp, and I counted about thirty people in the raffle, so at least 15% were newcomers who, I hope, felt that motto. Additionally, there was significant attendance at the Forcontu introduction to Drupal 10 course, partly because this year the Spanish Drupal Association found the right strategy to bring in students from various institutions. 

As for me, I believe the community remains healthy and strong.

The sessions

Since I still haven't mastered the art of being in two places at once and attending multiple talks simultaneously, I was only able to see a few and hear opinions on some others, so the selection I provide below is incomplete and biased, but I believe it's still interesting.

Drupal future

This year, Drupal Starshot initiative has been launched, aiming to create a new entry point for Drupal, which would be the default download from Drupal.org instead of the Drupal core. The…

Leveraging AI for Optimized Drupal Development: A New Era of Efficiency bhavinhjoshi Tue, 11/12/2024 - 14:12

In the world of web development, staying ahead means being willing to embrace innovation. One of the most transformative forces in technology today is Artificial Intelligence (AI), and its integration with Drupal development is proving to be a pivotal moment.

Why AI?

AI brings automation, precision, and speed to processes that were traditionally time-consuming and manually intensive. In the realm of Drupal development, these qualities unlock unprecedented possibilities, streamlining workflows and enhancing the overall quality of outcomes.

Automated Code Generation

One of the most practical applications of AI in Drupal development is automated code generation. AI tools, like machine learning algorithms, can automate repetitive coding tasks, freeing developers to focus on refining and innovating rather than getting bogged down in routine work.

Imagine AI-powered assistants generating initial code drafts or suggesting code snippets based on programming patterns. This capability can drastically reduce the time developers spend searching for syntax or debugging, accelerating the development cycle and increasing productivity.

Enhanced Security

AI's predictive capabilities allow for the identification and mitigation of potential security vulnerabilities before they become actual threats. In a Drupal environment, this proactive approach translates into safer websites and peace of mind for both developers and clients.

AI can analyze patterns in data traffic, detect anomalies that might suggest a security breach, and even suggest patches or updates to address these vulnerabilities swiftly.

Personalized User Experiences

The demand for personalized user experiences is growing, and AI is poised to meet this challenge head-on. By analyzing vast amounts of user data, AI can predict and tailor content delivery to individual preferences, enhancing engagement and retaining users on Drupal sites.

For instance, AI algorithms can determine the best times to display certain types of content or recommend products, ensuring users are met with relevant information every time they visit a site.

Efficient Data Analysis

Integrating AI with Drupal isn't just about improving front-end experiences, it also offers powerful data analysis capabilities. Developers can gain deep insights from user interactions and site performance metrics, leading to more informed, data-driven decisions that enhance site functionality and user satisfaction.

AI can detect patterns in user behavior, suggest optimizations for content delivery, and even predict future trends, enabling developers to remain agile and responsive to changing user needs.

Challenges and Considerations

While AI offers numerous benefits, it's essential to approach its integration with a clear understanding of its limitations and potential drawbacks. Navigating these challenges effectively requires a commitment to responsible AI usage and continuous learning. It's crucial to stay updated with the latest advancements and best practices. AI models can sometimes produce biased or unexpected results, making it important to have human oversight in place.

Ethical considerations are key. Developers need to ensure that AI tools are used to enhance the user experience while respecting privacy and data protection standards. Transparency with clients about AI interventions and data usage builds trust and aligns with ethical standards.

Training and skill development remain essential. As AI technologies evolve, so should the competencies of those who work with them. Investing in training ensures that teams are equipped to harness AI’s full potential effectively and responsibly.

In summary, AI is not just an add-on, it’s a transformative element that can elevate Drupal development to new heights of efficiency and innovation. By embracing AI thoughtfully, developers can not only streamline processes but also create more secure, personalized, and engaging digital experiences for users.

AI Drupal Drupal Planet Add new comment

Think you know JavaScript? Find out how native features can handle Objects and Arrays that simplify coding. No libraries necessary!

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian LTS contributors

In October, 20 contributors have been paid to work on Debian LTS, their reports are available:

• Abhijith PA did 6.0h (out of 7.0h assigned and 7.0h from previous period), thus carrying over 8.0h to the next month.
• Adrian Bunk did 15.0h (out of 87.0h assigned and 13.0h from previous period), thus carrying over 85.0h to the next month.
• Arturo Borrero Gonzalez did 10.0h (out of 10.0h assigned).
• Bastien Roucariès did 20.0h (out of 20.0h assigned).
• Ben Hutchings did 4.0h (out of 0.0h assigned and 4.0h from previous period).
• Chris Lamb did 18.0h (out of 18.0h assigned).
• Daniel Leidert did 29.0h (out of 26.0h assigned and 3.0h from previous period).
• Emilio Pozuelo Monfort did 60.0h (out of 23.5h assigned and 36.5h from previous period).
• Guilhem Moulin did 7.5h (out of 19.75h assigned and 0.25h from previous period), thus carrying over 12.5h to the next month.
• Lee Garrett did 15.25h (out of 0.0h assigned and 60.0h from previous period), thus carrying over 44.75h to the next month.
• Lucas Kanashiro did 10.0h (out of 10.0h assigned and 10.0h from previous period), thus carrying over 10.0h to the next month.
• Markus Koschany did 40.0h (out of 40.0h assigned).
• Ola Lundqvist did 14.5h (out of 6.5h assigned and 17.5h from previous period), thus carrying over 9.5h to the next month.
• Roberto C. Sánchez did 9.75h (out of 24.0h assigned), thus carrying over 14.25h to the next month.
• Santiago Ruano Rincón did 23.5h (out of 25.0h assigned), thus carrying over 1.5h to the next month.
• Sean Whitton did 6.25h (out of 1.0h assigned and 5.25h from previous period).
• Stefano Rivera did 1.0h (out of 0.0h assigned and 10.0h from previous period), thus carrying over 9.0h to the next month.
• Sylvain Beucler did 9.5h (out of 16.0h assigned and 44.0h from previous period), thus carrying over 50.5h to the next month.
• Thorsten Alteholz did 11.0h (out of 11.0h assigned).
• Tobias Frost did 10.5h (out of 12.0h assigned), thus carrying over 1.5h to the next month.

Evolution of the situation

In October, we have released 35 DLAs.

Some notable updates prepared in October include denial of service vulnerability fixes in nss, regression fixes in apache2, multiple fixes in php7.4, and new upstream releases of firefox-esr, openjdk-17, and opendk-11.

Additional contributions were made for the stable Debian 12 bookworm release by several LTS contributors. Arturo Borrero Gonzalez prepared a parallel update of nss, Bastien Roucariès prepared a parallel update of apache2, and Santiago Ruano Rincón prepared updates of activemq for both LTS and Debian stable.

LTS contributor Bastien Roucariès undertook a code audit of the cacti package and in the process discovered three new issues in node-dompurity, which were reported upstream and resulted in the assignment of three new CVEs.

As always, the LTS team continues to work towards improving the overall sustainability of the free software base upon which Debian LTS is built. We thank our many committed sponsors for their ongoing support.

Thanks to our sponsors

Sponsors that joined recently are in bold.

• Platinum sponsors:
  • Toshiba Corporation (for 109 months)
  • Civil Infrastructure Platform (CIP) (for 77 months)
  • VyOS Inc (for 41 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 119 months)
  • Akamai - Linode (for 113 months)
  • Babiel GmbH (for 103 months)
  • Plat’Home (for 102 months)
  • CINECA (for 77 months)
  • University of Oxford (for 59 months)
  • Deveryware (for 46 months)
  • EDF SA (for 31 months)
  • Dataport AöR (for 6 months)
  • CERN (for 4 months)
• Silver sponsors:
  • Domeneshop AS (for 124 months)
  • Nantes Métropole (for 118 months)
  • Univention GmbH (for 110 months)
  • Université Jean Monnet de St Etienne (for 110 months)
  • Ribbon Communications, Inc. (for 104 months)
  • Exonet B.V. (for 94 months)
  • Leibniz Rechenzentrum (for 88 months)
  • Ministère de l’Europe et des Affaires Étrangères (for 72 months)
  • Cloudways by DigitalOcean (for 61 months)
  • Dinahosting SL (for 59 months)
  • Bauer Xcel Media Deutschland KG (for 53 months)
  • Platform.sh SAS (for 53 months)
  • Moxa Inc. (for 47 months)
  • sipgate GmbH (for 45 months)
  • OVH US LLC (for 43 months)
  • Tilburg University (for 43 months)
  • GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 34 months)
  • Soliton Systems K.K. (for 31 months)
  • THINline s.r.o. (for 7 months)
  • Copenhagen Airports A/S
• Bronze sponsors:
  • Evolix (for 124 months)
  • Seznam.cz, a.s. (for 124 months)
  • Intevation GmbH (for 121 months)
  • Linuxhotel GmbH (for 121 months)
  • Daevel SARL (for 120 months)
  • Bitfolk LTD (for 119 months)
  • Megaspace Internet Services GmbH (for 119 months)
  • Greenbone AG (for 118 months)
  • NUMLOG (for 118 months)
  • WinGo AG (for 117 months)
  • Entr’ouvert (for 108 months)
  • Adfinis AG (for 106 months)
  • Tesorion (for 101 months)
  • GNI MEDIA (for 100 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 100 months)
  • Bearstech (for 92 months)
  • LiHAS (for 92 months)
  • Catalyst IT Ltd (for 87 months)
  • Supagro (for 82 months)
  • Demarcq SAS (for 81 months)
  • Université Grenoble Alpes (for 67 months)
  • TouchWeb SAS (for 59 months)
  • SPiN AG (for 56 months)
  • CoreFiling (for 52 months)
  • Institut des sciences cognitives Marc Jeannerod (for 47 months)
  • Observatoire des Sciences de l’Univers de Grenoble (for 43 months)
  • Tem Innovations GmbH (for 38 months)
  • WordFinder.pro (for 37 months)
  • CNRS DT INSU Résif (for 36 months)
  • Alter Way (for 29 months)
  • Institut Camille Jordan (for 19 months)
  • SOBIS Software GmbH (for 4 months)

Welcome to the @Krita-promo team's October 2024 development and community update.

Development Report Android-only Krita 5.2.8 Hotfix Release

Krita 5.2.6 was reported to crash on startup on devices running Android 14 or later. This was caused by issues with an SDK update required for release on the Play Store, so a temporary 5.2.7 release reverting it was available from the downloads page only.

However, the issue has now been resolved and 5.2.8 is rolling out on the Play Store. Note that 5.2.8 raises the minimum supported Android version to Android 7.0 (Nougat).

Community Bug Hunt Started

The development team has declared a "Bug Hunt Month" running through November, and needs the community's help to decide what to do with each and every one of the hundreds of open bug reports on the bug tracker. Which reports are valid and need to be fixed? Which ones need more info or are already resolved?

Read the bug hunting guide and join in on the bug hunt thread on the Krita-Artists forum.

Community Report October 2024 Monthly Art Challenge Results

For the "Buried, Stuck, or otherwise Swallowed" theme, 16 members submitted 18 original artworks. And the winner is… Tomorrow, contest… I’m so finished by @mikuma_poponta!

The November Art Challenge is Open Now

For the November Art Challenge, @mikuma_poponta has chosen "Fluffy" as the theme, with the optional challenge of making it "The Ultimate Fluffy According to Me". See the full brief for more details, and get comfortable with this month's theme.

Featured Artwork Best of Krita-Artists - September/October 2024

8 images were submitted to the Best of Krita-Artists Nominations thread, which was open from September 14th to October 11th. When the poll closed on October 14th, moderators had to break a four-way tie for the last two spots, resulting in these five wonderful works making their way onto the Krita-Artists featured artwork banner:

Sapphire by @Dehaf

Sci-Fi Spaceship by @NAKIGRAL

Oracular Oriole by @SylviaRitter

Air Port by @agarad

Dancing with butterflies 🦋 by @Kichirou_Okami

Best of Krita-Artists - October/November 2024

Nominations were accepted until November 11th. The poll is now open until November 14th. Don't forgot to vote!

Ways to Help Krita

Krita is Free and Open Source Software developed by an international team of sponsored developers and volunteer contributors.

Visit Krita's funding page to see how user donations keep development going, and explore a one-time or monthly contribution. Or check out more ways to Get Involved, from testing, coding, translating, and documentation writing, to just sharing your artwork made with Krita.

The Krita-promo team has put out a call for volunteers, come join us and help keep these monthly updates going.

Notable Changes

Notable changes in Krita's development builds from Oct. 10 - Nov. 12, 2024.

Stable branch (5.2.9-prealpha):

• Layers: Fix infinite loop when a clone layer is connected to a group with clones, and a filter mask triggers an out-of-bounds update. (Change, by Dmitry Kazakov)
• General: Fix inability to save a document after saving while the image is busy and then canceling the busy operation. (bug report) (Change, by Dmitry Kazakov)
• Resources: Fix crash when re-importing a resource after modifying it. (bug report) (Change, by Dmitry Kazakov)
• Brush Presets: Fix loading embedded resources from .kpp files. (bug report, bug report, bug report) (Change, by Dmitry Kazakov)
• Brush Tools: Fix the Dynamic Brush Tool to not use the Freehand Brush Tool's smoothing settings which it doesn't properly support. (bug report) (Change, by Mathias Wein)(Change, by Dmitry Kazakov)
• Recorder Docker: Prevent interruption of the Text Tool by disabling recording while it is active. (bug report) (Change, by Dmitry Kazakov)
• File Formats: EXR: Possibly fix saving EXR files with extremely low alpha values. (Change, by Dmitry Kazakov)
• File Formats: EXR: Try to keep color space profile when saving EXR of incompatible type. (Change, by Dmitry Kazakov)
• File Formats: EXR: Fix bogus offset when saving EXR with moved layers. (Change, by Dmitry Kazakov)
• File Formats: JPEG-XL: Fix potential lockup when loading multi-page images. (Change, by Rasyuqa A H)
• Keyboard Shortcuts: Set the default shortcut for Zoom In to = instead of +. (bug report) (Change, by Halla Rempt)
• Brush Editor: Make the Saturation and Value brush options' graph and graph labels consistently agree on the range being -100% to 100% with 0% as neutral. (bug report) (Change, by Dmitry Kazakov)

Unstable branch (5.3.0-prealpha):

Bug fixes:

• Vector Layers: Fix endlessly slow rendering of vector layers with clipping masks. (bug report) (Change, by Dmitry Kazakov)
• Layers: Fix issue with transform masks on group layers not showing until visibility change, and visibility change of passthrough groups with layer styles causing artifacts. (bug report) (Change, by Dmitry Kazakov)
• Brush Editor: Fix crash when clearing scratchpad while it's busy rendering a resource-intensive brushstroke. (bug report) (Change, by Dmitry Kazakov)
• File Formats: EXR: Add GUI option for selecting the default color space for EXR files. (Change, by Dmitry Kazakov)
• Transform Tool: Liquify: Move the Move/Rotate/Scale/Offset/Undo buttons to their own spot instead of alongside unrelated options, to avoid confusion. (bug report) (Change, by Emmet O'Neill)
• Move Tool: Fix Force Instant Preview in the Move tool to be off by default. (CCbug report) (Change, by Halla Rempt)
• Pop-Up Palette: Fix lag in selecting a color in the Pop-Up Palette. (bug report) (Change, by Dmitry Kazakov)
• Scripting: Fix accessing active node state from the Python scripts. (bug report) (Change, by Dmitry Kazakov)
• Usabillity: Remove unnecessary empty space at the bottom of Transform, Move and Crop tool options. (bug report) (Change, by Dmitry Kazakov)

Nightly Builds

Pre-release versions of Krita are built every day for testing new changes.

Get the latest bugfixes in Stable "Krita Plus" (5.2.9-prealpha): Linux - Windows - macOS (unsigned) - Android arm64-v8a - Android arm32-v7a - Android x86_64

Or test out the latest Experimental features in "Krita Next" (5.3.0-prealpha). Feedback and bug reports are appreciated!: Linux - Windows - macOS (unsigned) - Android arm64-v8a - Android arm32-v7a - Android x86_64

Have feedback?

Join the discussion of this post on the Krita-Artists forum!

In a previous post we saw that you can speed up code significantly on a single core using SIMD: Single Instruction Multiple Data. These specialized CPU instructions allow you to, for example, add 4 values at once with a single instruction, instead of the usual one value at a time. The performance improvement you get compounds with multi-core parallelism: you can benefit from both SIMD and threading at the same time.

Unfortunately, SIMD instructions are specific both to CPU architecture and CPU model. Thus ARM CPUs as used on modern Macs have different SIMD instructions than x86-64 CPUs. And even if you only care about x86-64, different models support different instructions; the i7-12700K CPU in my current computer doesn’t support AVX-512 SIMD, for example.

One way to deal with this is to write custom versions for each variation of SIMD instructions. Another is to use a portable SIMD library, that provides an abstraction layer on top of these various instruction sets.

In the previous post we used the std::simd library. It is built-in to the Rust standard library… but unfortunately it’s currently only available when using an unstable (“nightly”) compiler.

How you can write portable SIMD if you want to use stable Rust? In this article we’ll:

• Introduce the wide crate, that lets you write portable SIMD in stable Rust.
• Show how it can be used to reimplement the Mandelbrot algorithm we previously implemented with std::simd.
• Go over the pros and cons of these alternatives.

Read more...

Machine learning models are rapidly becoming more capable; how can we make use of these powerful new tools in our Go applications?

For top-of-the-line commercial LLMs like ChatGPT, Gemini or Claude, the models are exposed as language agnostic REST APIs. We can hand-craft HTTP requests or use client libraries (SDKs) provided by the LLM vendors. If we need more customized solutions, however, some challenges arise. Completely bespoke models are typically trained in Python using tools like TensorFlow, JAX or PyTorch that don't have real non-Python alternatives.

In this post, I will present some approaches for Go developers to use ML models in their applications - with increasing level of customization. The summary up front is that it's pretty easy, and we only have to deal with Python very minimally, if at all - depending on the circumstances.

Internet LLM services

This is the easiest category: multimodal services from Google, OpenAI and others are available as REST APIs with convenient client libraries for most leading languages (including Go), as well as third-party packages that provide abstractions on top (e.g. langchaingo).

Check out the official Go blog titled Building LLM-powered applications in Go that was published earlier this year. I've written about it before on this blog as well: #1, #2, #3 etc.

Go is typically as well supported as other programming languages in this domain; in fact, it's uniquely powerful for such applications because of its network-native nature; quoting from the Go blog post:

Working with LLM services often means sending REST or RPC requests to a network service, waiting for the response, sending new requests to other services based on that and so on. Go excels at all of these, providing great tools for managing concurrency and the complexity of juggling network services.

Since this has been covered extensively, let's move on to the more challenging scenarios.

Locally-running LLMs

There's a plethora of high-quality open models [1] one can choose from to run locally: Gemma, Llama, Mistral and many more. While these models aren't quite as capable as the strongest commercial LLM services, they are often surprisingly good and have clear benefits w.r.t. cost and privacy.

The industry has begun standardizing on some common formats for shipping and sharing these models - e.g. GGUF from llama.cpp, safetensors from Hugging Face or the older ONNX. Additionally, there are a number of excellent OSS tools that let us run such models locally and expose a REST API for an experience that's very similar to the OpenAI or Gemini APIs, including dedicated client libraries.

The best known such tool is probably Ollama; I've written extensively about it in the past: #1, #2, #3.

Ollama lets us customize an LLM through a Modelfile, which includes things like setting model parameters, system prompts etc. If we fine-tuned a model [2], it can also be loaded into Ollama by specifying our own GGUF file.

If you're running in a cloud environment, some vendors already have off-the-shelf solutions like GCP's Cloud Run integration that may be useful.

Ollama isn't the only player in this game, either; recently a new tool emerged with a slightly different approach. Llamafile distributes the entire model as a single binary, which is portable across several OSes and CPU architectures. Like Ollama, it provides REST APIs for the model.

If such a customized LLM is a suitable solution for your project, consider just running Ollama or Llamafile and using their REST APIs to communicate with the model. If you need higher degrees of customization, read on.

A note about the sidecar pattern

Before we proceed, I want to briefly discuss the sidecar pattern of application deployment. That k8s link talks about containers, but the pattern isn't limited to these. It applies to any software architecture in which functionality is isolated across processes.

Suppose we have an application that requires some library functionality; using Go as an example, we could find an appropriate package, import it and be on our way. Suppose there's no suitable Go package, however. If libraries exist with a C interface, we could alternatively use cgo to import it.

But say there's no C API either, for example if the functionality is only provided by a language without a convenient exported interface. Maybe it's in Lisp, or Perl, or... Python.

A very general solution could be to wrap the code we need in some kind of server interface and run it as a separate process; this kind of process is called a sidecar - it's launched specifically to provide additional functionality for another process. Whichever inter-process communication (IPC) mechanism we use, the benefits of this approach are many - isolation, security, language independence, etc. In today's world of containers and orchestration this approach is becoming increasingly more common; this is why many of the links about sidecars lead to k8s and other containerized solutions.

The Ollama approach outlined in the previous section is one example of using the sidecar pattern. Ollama provides us with LLM functionality but it runs as a server in its own process.

The solutions presented in the rest of this post are more explicit and fully worked-out examples of using the sidecar pattern.

Locally-running LLM with Python and JAX

Suppose none of the existing open LLMs will do for our project, even fine-tuned. At this point we can consider training our own LLM - this is hugely expensive, but perhaps there's no choice. Training usually involves one of the large ML frameworks like TensorFlow, JAX or PyTorch. In this section I'm not going to talk about how to train models; instead, I'll show how to run local inference of an already trained model - in Python with JAX, and use that as a sidecar server for a Go application.

The sample (full code is here) is based on the official Gemma repository, using its sampler library [3]. It comes with a README that explains how to set everything up. This is the relevant code instantiating a Gemma sampler:

# Once initialized, this will hold a sampler_lib.Sampler instance that # can be used to generate text. gemma_sampler = None def initialize_gemma(): """Initialize Gemma sampler, loading the model into the GPU.""" model_checkpoint = os.getenv("MODEL_CHECKPOINT") model_tokenizer = os.getenv("MODEL_TOKENIZER") parameters = params_lib.load_and_format_params(model_checkpoint) print("Parameters loaded") vocab = spm.SentencePieceProcessor() vocab.Load(model_tokenizer) transformer_config = transformer_lib.TransformerConfig.from_params( parameters, cache_size=1024, ) transformer = transformer_lib.Transformer(transformer_config) global gemma_sampler gemma_sampler = sampler_lib.Sampler( transformer=transformer, vocab=vocab, params=parameters["transformer"], ) print("Sampler ready")

The model weights and tokenizer vocabulary are files downloaded from Kaggle, per the instructions in the Gemma repository README.

So we have LLM inference up and running in Python; how do we use it from Go?

Using a sidecar, of course. Let's whip up a quick web server around this model and expose a trivial REST interface on a local port that Go (or any other tool) can talk to. As an example, I've set up a Flask-based web server around this inference code. The web server is invoked with gunicorn - see the shell script for details.

Excluding the imports, here's the entire application code:

def create_app(): # Create an app and perform one-time initialization of Gemma. app = Flask(__name__) with app.app_context(): initialize_gemma() return app app = create_app() # Route for simple echoing / smoke test. @app.route("/echo", methods=["POST"]) def echo(): prompt = request.json["prompt"] return {"echo_prompt": prompt} # The real route for generating text. @app.route("/prompt", methods=["POST"]) def prompt(): prompt = request.json["prompt"] # For total_generation_steps, 128 is a default taken from the Gemma # sample. It's a tradeoff between speed and quality (higher values mean # better quality but slower generation). # The user can override this value by passing a "sampling_steps" key in # the request JSON. sampling_steps = request.json.get("sampling_steps", 128) sampled_str = gemma_sampler( input_strings=[prompt], total_generation_steps=int(sampling_steps), ).text return {"response": sampled_str}

The server exposes two routes:

• prompt: a client sends in a textual prompt, the server runs Gemma inference and returns the generated text in a JSON response
• echo: used for testing and benchmarking

Here's how it all looks tied together:

The important takeaway is that this is just an example. Literally any part of this setup can be changed: one could use a different ML library (maybe PyTorch instead of JAX); one could use a different model (not Gemma, not even an LLM) and one can use a different setup to build a web server around it. There are many options, and each developer will choose what fits their project best.

It's also worth noting that we've written less than 100 lines of Python code in total - much of it piecing together snippets from tutorials. This tiny amount of Python code is sufficient to wrap an HTTP server with a simple REST interface around an LLM running locally through JAX on the GPU. From here on, we're safely back in our application's actual business logic and Go.

Now, a word about performance. One of the concerns developers may have with sidecar-based solutions is the performance overhead of IPC between Python and Go. I've added a simple echo endpoint to measure this effect; take a look at the Go client that exercises it; on my machine the latency of sending a JSON request from Go to the Python server and getting back the echo response is about 0.35 ms on average. Compared to the time it takes Gemma to process a prompt and return a response (typically measured in seconds, or maybe hundreds of milliseconds on very powerful GPUs), this is entirely negligible.

That said, not every custom model you may need to run is a full-fledged LLM. What if your model is small and fast, and the overhead of 0.35 ms becomes significant? Worry not, it can be optimized. This is the topic of the next section.

Locally-running fast image model with Python and TensorFlow

The final sample of this post mixes things up a bit:

• We'll be using a simple image model (instead of an LLM)
• We're going to train it ourselves using TensorFlow+Keras (instead of JAX)
• We'll use a different IPC method between the Python sidecar server and clients (instead of HTTP+REST)

The model is still implemented in Python, and it's still driven as a sidecar server process by a Go client [4]. The idea here is to show the versatility of the sidecar approach, and to demonstrate a lower-latency way to communicate between the processes.

The full code of the sample is here. It trains a simple CNN (convolutional neural network) to classify images from the CIFAR-10 dataset:

The neural net setup with TensorFlow and Keras was taken from an official tutorial. Here's the entire network definition:

model = models.Sequential() model.add(layers.Conv2D(32, (3, 3), activation="relu", input_shape=(32, 32, 3))) model.add(layers.MaxPooling2D((2, 2))) model.add(layers.Conv2D(64, (3, 3), activation="relu")) model.add(layers.MaxPooling2D((2, 2))) model.add(layers.Conv2D(64, (3, 3), activation="relu")) model.add(layers.Flatten()) model.add(layers.Dense(64, activation="relu")) model.add(layers.Dense(10))

CIFAR-10 images are 32x32 pixels, each pixel being 3 values for red, green and blue. In the original dataset, these values are bytes in the inclusive range 0-255 representing color intensity. This should explain the (32, 32, 3) shape appearing in the code. The full code for training the model is in the train.py file in the sample; it runs for a bit and saves the serialized model along with the trained weights into a local file.

The next component is an "image server": it loads the trained model+weights file from disk and runs inference on images passed into it, returning the label the model thinks is most likely for each.

The server doesn't use HTTP and REST, however. It creates a Unix domain socket and uses a simple length-prefix encoding protocol to communicate:

Each packet starts with a 4-byte field that specifies the length of the rest of the contents. A type is a single byte, and the body can be anything [5]. In the sample image server two commands are currently supported:

• 0 means "echo" - the server will respond with the same packet back to the client. The contents of the packet body are immaterial.
• 1 means "classify" - the packet body is interpreted as a 32x32 RGB image, encoded as the red channel for each pixel in the first 1024 bytes (32x32, row major), then green in the next 1024 bytes and finally blue in the last 1024 bytes. Here the server will run the image through the model, and reply with the label the model thinks describes the image.

The sample also includes a simple Go client that can take a PNG file from disk, encode it in the required format and send it over the domain socket to the server, recording the response.

The client can also be used to benchmark the latency of a roundtrip message exchange. It's easier to just show the code instead of explaining what it does:

func runBenchmark(c net.Conn, numIters int) { // Create a []byte with 3072 bytes. body := make([]byte, 3072) for i := range body { body[i] = byte(i % 256) } t1 := time.Now() for range numIters { sendPacket(c, messageTypeEcho, body) cmd, resp := readPacket(c) if cmd != 0 || len(resp) != len(body) { log.Fatal("bad response") } } elapsed := time.Since(t1) fmt.Printf("Num packets: %d, Elapsed time: %s\n", numIters, elapsed) fmt.Printf("Average time per request: %d ns\n", elapsed.Nanoseconds()/int64(numIters)) }

In my testing, the average latency of a roundtrip is about 10 μs (that's micro-seconds). Considering the size of the message and it being Python on the other end, this is roughly in-line with my earlier benchmarking of Unix domain socket latency in Go.

How long does a single image inference take with this model? In my measurements, about 3 ms. Recall that the communication latency for the HTTP+REST approach was 0.35 ms; while this is only 12% of the image inference time, it's close enough to be potentially worrying. On a beefy server-class GPU the time can be much shorter [6].

With the custom protocol over domain sockets, the latency - being 10 μs - seems quite negligible no matter what you end up running on your GPU.

Code

The full code for the samples in this post is on GitHub.

[1]To be pedantic, these models are not entirely open: their inference architecture is open-source and their weights are available, but the details of their training remain proprietary. [2]The details of fine-tuning models are beyond the scope of this post, but there are plenty resources about this online. [3]"Sampling" in LLMs means roughly "inference". A trained model is fed an input prompt and then "sampled" to produce its output. [4]In my samples, the Python server and Go client simply run in different terminals and talk to each other. How service management is structured is very project-specific. We could envision an approach wherein the Go application launches the Python server to run in the background and communicates with it. Increasingly likely these days, however, would be a container-based setup, where each program is its own container and an orchestration solution launches and manages these containers. [5]You may be wondering why I'm implementing a custom protocol here instead of using something established. In real life, I'd definitely recommend using something like gRPC. However, for the sake of this sample I wanted something that would be (1) simple without additional libraries and (2) very fast. FWIW, I don't think the latency numbers would be very much different for gRPC. Check out my earlier post about RPC over Unix domain sockets in Go. [6]On the other hand, the model I'm running here is really small. It's fair to say realistic models you'll use in your application will be much larger and hence slower.

Today we are talking about Workspaces, What They are, and How They Work with guest Scott Weston. We’ll also cover Workspaces Extra as our module of the week.

For show notes visit: https://www.talkingDrupal.com/475

Topics

• What are Workspaces in Drupal
• What's a common use cases for Workspaces
• Are Workspaces stable
• Do Workspaces help with content versioning
• What does the module ecosystem look like for Workspaces
• Inspiration
• Workspaces best practices
• Any interesting ways it is being used
• Is there a way to access workspace content in twig
• Navigation integration
• Workspaces and workflows
• What aspects of a Workspace are limited to live
• If someone wants to get involved or get started

Resources

• Drupal Workspaces
• Core issue: Media library form can only be submitted in the default workspace
• Integrate Navigation with Workspaces

Guests

Scott Weston - scott-weston

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Joshua "Josh" Mitchell - joshuami.com joshuami

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Do you want to extend the capabilities of the Workspaces system in Drupal core? There’s a module for that.
• Module name/project name:
  • Workspaces Extra
• Brief history
  • How old: created in Apr 2021 by Andrei Mateescu (amateescu) of tag1, who has also contributed to Workspaces in core, among other many things
  • Versions available: 2.0.0-alpha3 which works with Drupal 10.3 or 11
• Maintainership
  • Actively maintained, latest release is less than a week old
  • Security coverage: technically yes, but not really until it has a stable release
  • Test coverage
  • Number of open issues: 20 open issues, 3 of which are bugs against the current branch, though one has already been fixed
• Usage stats:
  • 89 sites
• Module features and usage
  • One of the big features in Drupal 10.3 was that Workspaces is now officially stable. That said, not everything works the way some site builders will want it to. That’s where a contrib solution like Workspace Extra can help to fill in the gaps
  • It provides new options like letting you roll back changes from a published workspace, move content between workspaces, discard changes in a workspace, squashing content revisions when a workspace is published, and more
  • Workspaces Extra, or WSE also includes a number of submodules to add even more capabilities. For example, they can allow your workspace to stage an allowlist of configuration changes, deploy workspace content using an import/export system, stage menu changes, and more. For workflow, there’s an option to generate a shareable workspace preview link for external users, and a scheduler to publish your workspace at a specific day and time
  • I will add that the first time I played with workspaces I ran into an issue where I couldn’t create media entities within a workspace. I don’t know for sure that this hasn’t been fixed in core, but the core issue about it is still listed as “Needs work”. That said, the last comment on that issue (link in the show notes) lists WSE as something that helps, so if you encounter the same issue with Workspaces, WSE is worth a try

It’s been a minute!

We have been hard at work making sure our design system keeps moving forward. For the past weeks, we have made significant progress in the space of color creation and icons.

There is also an easter egg in the form of PenPot. Read the rest!

As previously mentioned, we restructured our color palettes to have set color variations at various levels. We will combine those colors into tokens that will be named something like this:

pd.sys.color.red50

Meaning:

• PD: Plasma Design
• SYS: System token (We also have reference tokens and component tokens, .ref. and .com. respectively)
• Color: Token type
• red50: color name + color value

Note that as we follow Material design guidelines for these colors, we have a collection of 100 different color shades for a given color. Depending on the needs of the system or changes in design, we could decide to not use red50 but we would like more intensity. So we would choose red49, or red48, and so on.

The color variable name would change accordingly. This set up would allow designers and developers to understand the kind of token they are working with and it would be the same language for both developer and designer.

In Figma and PenPot, designers have the ability to name tokens however they like. I opted for keeping token names as we are recommending them for the Plasma system. That way there is good consistency.

This week, we consolidated these colors and we added them to the list of tokens in Figma and PenPot. However, there is still more to be done in the form of documentation for our Plasma developer team. We are still working through it, making sure we are accurate in the request for development.

Additionally, this week we had the pleasure to meet with Pablo Ruiz, CEO at PenPot. Mike, one of our team members met Pablo recently and spoke of our Plasma Next project. This led to a meeting to discuss the needs that our team currently has for developing a design system.

The team at PenPot is excited to partner with our KDE team and the Plasma Next initiative. They have generously offered a few resources to help.

This couldn’t come at a better time as very recently we have been hitting gaps in our team knowledge when it comes to developing design systems. This process is a first for our desktop system and we want to get it right. With the help of the PenPot team and the changes they are making to the application, this should be easier.

As such, we also decided to request prioritization for some of our tickets that would allow us to set up and migrate our Figma assets into PenPot and eventually, share these with the community at large.

Today, we are not close to releasing a full design system for others to use, but we are making good progress. Stay tuned!

We also moved into the process of editing 16px icons. Given that we already have new icons in the 24px collection that we can leverage, we cut the design time in half or more. We don’t have to brainstorm new icons, we mostly just have to edit the 24px icon and adapt it to a 16px version. This work just barely started but we are making good progress.

One area that is still up in the air is our colorful icons. Given we edited the monochrome icons, this calls for editing colorful icons as well. We have received many suggestions on what kind of colorful style we should follow. I would like to extend that invitation.

If you have seen or created amazing colorful icons and would like to suggest that style for us at Plasma, send us a comment!

That’s it for this week. Good progress so far!

Version 0.0.19 of RcppSpdlog arrived on CRAN early this morning and has been uploaded to Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.

This releases updates the code to the version 1.15.0 of spdlog which was released on Saturday, and contains fmt 11.0.2. It also contains a contributed PR which allows use std::format under C++20, bypassing fmt (with some post-merge polish too), and another PR correcting a documentation double-entry.

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.19 (2024-11-10)

• Support use of std::format under C++20 via opt-in define instead of fmt (Xanthos Xanthopoulos in #19)

• An erroneous duplicate log=level documentation level was removed (Contantinos Giachalis in #20)

• Upgraded to upstream release spdlog 1.15.0 (Dirk in #21)

• Partially revert / simplify src/formatter.cpp accomodating both #19 and previous state (Dirk in #21)

Courtesy of my CRANberries, there is also a diffstat report. More detailed information is on the RcppSpdlog page, or the package documention site. If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

This post is a review for Computing Reviews for Why academics under-share research data - A social relational theory , a article published in Journal of the Association for Information Science and Technology

As an academic, I have cheered for and welcomed the open access (OA) mandates that, slowly but steadily, have been accepted in one way or another throughout academia. It is now often accepted that public funds means public research. Many of our universities or funding bodies will demand that, with varying intensities–sometimes they demand research to be published in an OA venue, sometimes a mandate will only “prefer” it. Lately, some journals and funder bodies have expanded this mandate toward open science, requiring not only research outputs (that is, articles and books) to be published openly but for the data backing the results to be made public as well. As a person who has been involved with free software promotion since the mid 1990s, it was natural for me to join the OA movement and to celebrate when various universities adopt such mandates.

Now, what happens after a university or funder body adopts such a mandate? Many individual academics cheer, as it is the “right thing to do.” However, the authors observe that this is not really followed thoroughly by academics. What can be observed, rather, is the slow pace or “feet dragging” of academics when they are compelled to comply with OA mandates, or even an outright refusal to do so. If OA and open science are close to the ethos of academia, why aren’t more academics enthusiastically sharing the data used for their research? This paper finds a subversive practice embodied in the refusal to comply with such mandates, and explores an hypothesis based on Karl Marx’s productive worker theory and Pierre Bourdieu’s ideas of symbolic capital.

The paper explains that academics, as productive workers, become targets for exploitation: given that it’s not only the academics’ sharing ethos, but private industry’s push for data collection and industry-aligned research, they adapt to technological changes and jump through all kinds of hurdles to create more products, in a result that can be understood as a neoliberal productivity measurement strategy. Neoliberalism assumes that mechanisms that produce more profit for academic institutions will result in better research; it also leads to the disempowerment of academics as a class, although they are rewarded as individuals due to the specific value they produce.

The authors continue by explaining how open science mandates seem to ignore the historical ways of collaboration in different scientific fields, and exploring different angles of how and why data can be seen as “under-shared,” failing to comply with different aspects of said mandates. This paper, built on the social sciences tradition, is clearly a controversial work that can spark interesting discussions. While it does not specifically touch on computing, it is relevant to Computing Reviews readers due to the relatively high percentage of academics among us.

The latest Python developments all point to the same thing—Python is currently thriving. The recent GitHub Octoverse 2024 report has revealed that Python is now the most used language on GitHub. Also, last month saw the release of Python 3.13, which is already laying the groundwork for some exciting future improvements.

While Python core developers have been busy exploring the language’s features as they tinker with upcoming enhancements, it’s good to know that working on Python’s source code isn’t the only way you can contribute to Python’s future. Another way to shape the focus of upcoming releases is to join the Python Developers Survey 2024.

And with the end of the year in sight, you may want to venture a look at next year’s calendar and mark some dates, such as the PyCon US conference in May or the Python 3.14 release in October 2025.

Now that you know the highlights, it’s time to dive into the most important Python news for November.

Join Now: Click here to join the Real Python Newsletter and you'll never miss another Python tutorial, course update, or post.

Python’s Popularity Shines in GitHub’s Octoverse 2024

The latest Octoverse report for 2024 shows that Python remains one of the most widely used languages on GitHub, securing its place as a core language in open-source and professional development. Python ranked among the top three most-used languages, demonstrating its continued appeal across industries and experience levels:

As GitHub’s annual report illustrates, Python’s popularity is fueled by its solid role in developing machine learning and artificial intelligence frameworks.

Another takeaway from the Octoverse survey is Python’s strong community engagement. Python developers are not only active in contributing code but also in participating in discussions, filing issues, and reviewing pull requests.

Read the full article at https://realpython.com/python-news-november-2024/ »

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

Hi there!

I'm happy to announce version 3.15 of reader, a Python feed reader library.

What's new? #

Here are the highlights since reader 3.13.

Retry-After #

Now that it supports scheduled updates, reader can honor the Retry-After HTTP header sent with 429 Too Many Requests or 503 Service Unavailable responses.

Adding this required an extensive rework of the parser internal API, but I'd say it was worth it, since we're getting quite close to it becoming stable.

Next up in HTTP compliance is to do more on behalf of the user: bump the update interval on repeated throttling, and handle gone and redirected feeds accordingly.

Faster tag filters, feed slugs #

OR-only tag filters like get_feeds(tags=[['one', 'two']]) now use an index.

This is useful for maintaining a reverse mapping to feeds/entries, like the feed slugs recipe does to add support for user-defined short URLs:

>>> url = 'https://death.andgravity.com/_feed/index.xml' >>> reader.set_feed_slug(url, 'andgravity') >>> reader.get_feed_by_slug('andgravity') Feed(url='https://death.andgravity.com/_feed/index.xml', ...)

(Interested in adopting this recipe as a real plugin? Submit a pull request!)

enclosure_tags improvements #

The enclosure_tags plugin fixes ID3 tags for MP3 enclosures like podcasts.

I've changed the implementation to rewrite tags on the fly, instead of downloading the entire file, rewriting tags, and then sending it to the user; this should allow browsers to display accurate download progress.

Some other, smaller improvements:

• Set genre to Podcast if the feed has any tag containing "podcast".
• Prefer feed user title to feed title if available.
• Use feed title as artist, instead of author.

Using the installed feedparser #

Because feedparser makes PyPI releases at a lower cadence, reader has been using a vendored version of feedparser's develop branch for some time. It is now possible to opt out of this behavior and make reader use the installed feedparser package.

Python versions #

reader 3.14 (released back in July) adds support for Python 3.13.

That's it for now. For more details, see the full changelog.

Want to contribute? Check out the docs and the roadmap.

Learned something new today? Share this with others, it really helps! PyCoder's Weekly HN Reddit linkedin Twitter

What is reader? #

reader takes care of the core functionality required by a feed reader, so you can focus on what makes yours different.

reader allows you to:

• retrieve, store, and manage Atom, RSS, and JSON feeds
• mark articles as read or important
• add arbitrary tags/metadata to feeds and articles
• filter feeds and articles
• full-text search articles
• get statistics on feed and user activity
• write plugins to extend its functionality

...all these with:

• a stable, clearly documented API
• excellent test coverage
• fully typed Python

To find out more, check out the GitHub repo and the docs, or give the tutorial a try.

Why use a feed reader library? #

Have you been unhappy with existing feed readers and wanted to make your own, but:

• never knew where to start?
• it seemed like too much work?
• you don't like writing backend code?

Are you already working with feedparser, but:

• want an easier way to store, filter, sort and search feeds and entries?
• want to get back type-annotated objects instead of dicts?
• want to restrict or deny file-system access?
• want to change the way feeds are retrieved by using Requests?
• want to also support JSON Feed?
• want to support custom information sources?

... while still supporting all the feed types feedparser does?

If you answered yes to any of the above, reader can help.

The reader philosophy #

• reader is a library
• reader is for the long term
• reader is extensible
• reader is stable (within reason)
• reader is simple to use; API matters
• reader features work well together
• reader is tested
• reader is documented
• reader has minimal dependencies

Why make your own feed reader? #

So you can:

• have full control over your data
• control what features it has or doesn't have
• decide how much you pay for it
• make sure it doesn't get closed while you're still using it
• really, it's easier than you think

Obviously, this may not be your cup of tea, but if it is, reader can help.

A Python f-string (formatted string literal) allows you to insert variables or expressions directly into a string by placing them inside curly braces {}. In this tutorial, you will learn about the Pyt

Caddy is an open-source web server written in Go. It handles TLS certificates automatically and comes with a simple configuration syntax. Users can extend its functionality through plugins1 to add features like rate limiting, caching, and Docker integration.

While Caddy is available in Nixpkgs, adding extra plugins is not simple.2 The compilation process needs Internet access, which Nix denies during build to ensure reproducibility. When trying to build the following derivation using xcaddy, a tool for building Caddy with plugins, it fails with this error: dial tcp: lookup proxy.golang.org on [::1]:53: connection refused.

{ pkgs }: pkgs.stdenv.mkDerivation { name = "caddy-with-xcaddy"; nativeBuildInputs = with pkgs; [ go xcaddy cacert ]; unpackPhase = "true"; buildPhase = '' xcaddy build --with github.com/caddy-dns/powerdns@v1.0.1 ''; installPhase = '' mkdir -p $out/bin cp caddy $out/bin ''; }

Fixed-output derivations are an exception to this rule and get network access during build. They need to specify their output hash. For example, the fetchurl function produces a fixed-output derivation:

{ stdenv, fetchurl }: stdenv.mkDerivation rec { pname = "hello"; version = "2.12.1"; src = fetchurl { url = "mirror://gnu/hello/hello-${version}.tar.gz"; hash = "sha256-jZkUKv2SV28wsM18tCqNxoCZmLxdYH2Idh9RLibH2yA="; }; }

To create a fixed-output derivation, you need to set the outputHash attribute. The example below shows how to output Caddy’s source code, with some plugin enabled, as a fixed-output derivation using xcaddy and go mod vendor.

pkgs.stdenvNoCC.mkDerivation rec { pname = "caddy-src-with-xcaddy"; version = "2.8.4"; nativeBuildInputs = with pkgs; [ go xcaddy cacert ]; unpackPhase = "true"; buildPhase = '' export GOCACHE=$TMPDIR/go-cache export GOPATH="$TMPDIR/go" XCADDY_SKIP_BUILD=1 TMPDIR="$PWD" \ xcaddy build v${version} --with github.com/caddy-dns/powerdns@v1.0.1 (cd buildenv* && go mod vendor) ''; installPhase = '' mv buildenv* $out ''; outputHash = "sha256-F/jqR4iEsklJFycTjSaW8B/V3iTGqqGOzwYBUXxRKrc="; outputHashAlgo = "sha256"; outputHashMode = "recursive"; }

With a fixed-output derivation, it is up to us to ensure the output is always the same:

• we ask xcaddy to not compile the program and keep the source code,3
• we pin the version of Caddy we want to build, and
• we pin the version of each requested plugin.

You can use this derivation to override the src attribute in pkgs.caddy:

pkgs.caddy.overrideAttrs (prev: { src = pkgs.stdenvNoCC.mkDerivation { /* ... */ }; vendorHash = null; subPackages = [ "." ]; });

Check out the complete example in the GitHub repository. To integrate into a Flake, add github:vincentbernat/caddy-nix as an overlay:

{ inputs = { nixpkgs.url = "nixpkgs"; flake-utils.url = "github:numtide/flake-utils"; caddy.url = "github:vincentbernat/caddy-nix"; }; outputs = { self, nixpkgs, flake-utils, caddy }: flake-utils.lib.eachDefaultSystem (system: let pkgs = import nixpkgs { inherit system; overlays = [ caddy.overlays.default ]; }; in { packages = { default = pkgs.caddy.withPlugins { plugins = [ "github.com/caddy-dns/powerdns@v1.0.1" ]; hash = "sha256-Vh7JP6RK23Y0E5IDJ3zbBCnF3gKPIav05OMI4ALIcZg="; }; }; }); }

1. This article uses the term “plugins,” though Caddy documentation also refers to them as “modules” since they are implemented as Go modules. ↩︎

2. This is a feature request since quite some time. A proposed solution has been rejected. The one described in this article is a bit different. ↩︎

3. This is not perfect: if the source code produced by xcaddy changes, the hash would change and the build would fail. ↩︎