Feeds

Real Python: Quiz: Using Python's pip to Manage Your Projects' Dependencies

Planet Python - Tue, 2024-09-17 08:00

In this quiz, you’ll test your understanding of Python’s standard package manager, pip. You’ll revisit the concepts behind pip, important commands, and how to install packages.

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

Categories: FLOSS Project Planets

Drupal life hack's: Mastering Dependency Injection in Drupal: A Practical Guide

Planet Drupal - Tue, 2024-09-17 06:37
Mastering Dependency Injection in Drupal: A Practical Guide admin Tue, 09/17/2024 - 13:37
Categories: FLOSS Project Planets

Python Bytes: #401 We must replace uWSGI with something else

Planet Python - Tue, 2024-09-17 04:00
<strong>Topics covered in this episode:</strong><br> <ul> <li><strong>“<a href="https://github.com/overhangio/tutor/issues/937?featured_on=pythonbytes">We must replace uwsgi by something else</a>”</strong></li> <li><strong><a href="https://pythonspeed.com/articles/intro-rust-python-extensions?utm_source=pocket_shared&featured_on=pythonbytes">Let’s build and optimize a Rust extension for Python</a></strong></li> <li><strong><a href="https://www.reversinglabs.com/blog/fake-recruiter-coding-tests-target-devs-with-malicious-python-packages?featured_on=pythonbytes">Fake recruiter coding tests target devs with malicious Python packages</a></strong></li> <li><a href="https://pyfound.blogspot.com/2024/08/ask-questions-or-tell-us-what-you-think.html?utm_source=pocket_shared&featured_on=pythonbytes"><strong>Monthly PSF Board Office Hours</strong></a></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=XKI5gtnKMus' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="401">Watch on YouTube</a><br> <p><strong>About the show</strong></p> <p>Sponsored by ScoutAPM: <a href="https://pythonbytes.fm/scout"><strong>pythonbytes.fm/scout</strong></a></p> <p><strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy"><strong>@mkennedy@fosstodon.org</strong></a></li> <li>Brian: <a href="https://fosstodon.org/@brianokken"><strong>@brianokken@fosstodon.org</strong></a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes"><strong>@pythonbytes@fosstodon.org</strong></a></li> </ul> <p>Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/live</strong></a> to be part of the audience. Usually <strong>Monday</strong> at 10am PT. Older video versions available there too.</p> <p>Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to <a href="https://pythonbytes.fm/friends-of-the-show">our friends of the show list</a>, we'll never share it.</p> <p><strong>Michael #1:</strong> <strong>“<a href="https://github.com/overhangio/tutor/issues/937?featured_on=pythonbytes">We must replace uwsgi by something else</a>”</strong></p> <ul> <li>uWSGI is now in maintenance mode: https://uwsgi-docs.readthedocs.io/en/latest/ <ul> <li><em>The project is in maintenance mode</em> <em>(only</em> <em>bugfixes and updates for new languages apis). Do not expect quick answers on github issues and/or pull requests</em> <em>(sorry</em> <em>for that) A big thanks to all of the users and contributors since 2009.</em></li> </ul></li> <li>Reasonable options look like: <ul> <li><a href="https://github.com/emmett-framework/granian?featured_on=pythonbytes">granian</a></li> <li><a href="https://www.uvicorn.org?featured_on=pythonbytes">uvicorn</a></li> <li><a href="https://hypercorn.readthedocs.io/en/latest/index.html?featured_on=pythonbytes">hypercorn</a></li> <li><a href="https://gunicorn.org?featured_on=pythonbytes">gunicorn</a> (potentially with uvicorn workers for async)</li> </ul></li> </ul> <p><strong>Brian #2:</strong> <a href="https://pythonspeed.com/articles/intro-rust-python-extensions?utm_source=pocket_shared&featured_on=pythonbytes">Let’s build and optimize a Rust extension for Python</a></p> <ul> <li>Itamar Turner-Trauring</li> <li>Example: algorithm for approximating the number of unique values in a list</li> <li>Comparison to non-approximation <ul> <li>non-approx is faster but uses way more memory</li> </ul></li> <li>Rust version <ul> <li>Use Maturin and PyO3</li> <li>Pull in Rust dependencies (rand for random numbers)</li> </ul></li> <li>Optimization <ul> <li>link-time optimization</li> <li>faster random</li> <li>store hashes only</li> </ul></li> <li>Future optimizations <ul> <li>change algorithm maybe</li> <li>pass numpy array instead of Python list (I’d like to see that spedup)</li> </ul></li> </ul> <p><strong>Michael #3:</strong> <a href="https://www.reversinglabs.com/blog/fake-recruiter-coding-tests-target-devs-with-malicious-python-packages?featured_on=pythonbytes">Fake recruiter coding tests target devs with malicious Python packages</a></p> <ul> <li>via python weekly</li> <li>GitHub projects that have been linked to previous, targeted attacks in which developers are lured using fake job interviews.</li> <li>Attackers posing as employees of major financial services firms.</li> <li>This previously happened via other means such as NPM</li> <li>This analysis revealed that the direct parent of the detected, malicious files is a PythonPYC file, meaning that once again the team encountered malware hidden in a compiled Python file.</li> <li>“The README files tell would-be candidates to make sure the project is running successfully on their system before making modifications.”</li> <li>What can you do (according to Michael)? <ul> <li>Try out new packages in a docker container</li> <li>Work on code and projects using a VM which has snapshotting (to roll back completely after you’re done)</li> <li>Fire up <a href="https://learn.microsoft.com/en-us/azure/virtual-desktop/users/connect-windows?pivots=remote-desktop-msi&featured_on=pythonbytes">a Windows desktop in the cloud</a> for the project then destroy it</li> </ul></li> </ul> <p><strong>Brian #4:</strong> <a href="https://pyfound.blogspot.com/2024/08/ask-questions-or-tell-us-what-you-think.html?utm_source=pocket_shared&featured_on=pythonbytes"><strong>Monthly PSF Board Office Hours</strong></a></p> <ul> <li>“The Office Hours will be sessions where you can share with us how we can help your community, express your perspectives, and provide feedback for the PSF.”</li> <li>“Unless we have a dedicated topic for a session, you are not limited to talking with us about the above topics, although the discussions should be focused on Python, the PSF, and our community. If you think there’s something we can help with or we should know, we welcome you to come and talk to us!”</li> <li>Upcoming office hours <ul> <li>October 8th, 2024: 9pm UTC</li> <li>November 12th, 2024: 2pm UTC</li> <li>December 10th, 2024: 9pm UTC</li> <li>January 14th, 2025: 2pm UTC</li> <li>February 11th, 2025: 9pm UTC</li> <li>March 11th, 2025: 1pm UTC</li> <li>April 8th, 2025: 9pm UTC</li> <li>May 13th, 2025: 1pm UTC (Live from PyCon US!)</li> <li>June 10th, 2025: 9pm UTC</li> <li>July 9th, 2025: 1pm UTC</li> <li>August 12th, 2025: 9pm UTC</li> </ul></li> </ul> <p><strong>Extras</strong> </p> <p>Brian:</p> <ul> <li><a href="https://2025.pycascades.com?featured_on=pythonbytes">PyCascades CFP closes Friday, Sept 20</a> <ul> <li>PyCascades is in Portland in 2025 (Feb 8 &amp; 9)</li> </ul></li> <li><p>uv <a href="https://github.com/astral-sh/uv/pull/7263?featured_on=pythonbytes">now supports Python 3.13.0rc2</a></p> <pre><code>uv self update uv venv -p 3.13 </code></pre></li> <li><p><a href="https://github.com/astral-sh/uv/issues/7193?featured_on=pythonbytes">Free threaded is still an open issue</a></p></li> </ul> <p>Michael:</p> <ul> <li><a href="https://www.humblebundle.com/software/next-level-python-from-talk-python-and-friends-software?featured_on=pythonbytes">Big Python Humble Bundle with both of our products</a> <ul> <li>Get $1,800 worth of Python content and tools for $30 and contribute to charity</li> <li>Includes 5 <a href="https://training.talkpython.fm/courses/all?featured_on=pythonbytes">Talk Python courses</a></li> <li>Several of Brian’s and his book</li> </ul></li> <li><a href="https://djangonaut.space/comms/2024-opening-session-3/?featured_on=pythonbytes">Djangonaut Space Session 3 Applications Open!</a> <ul> <li>I interviewed <a href="https://talkpython.fm/episodes/show/451/djangonauts-ready-for-blast-off?featured_on=pythonbytes">Sarah and Tushar on Talk Python</a></li> </ul></li> <li><a href="https://alt-tab-macos.netlify.app?featured_on=pythonbytes">AltTab: Windows alt-tab on macOS</a></li> </ul> <p><strong>Joke:</strong> <a href="https://devhumor.com/media/elections-403-for-bidden?featured_on=pythonbytes">Election joke</a></p>
Categories: FLOSS Project Planets

Specbee: Cooking up irresistible Drupal websites with Recipes

Planet Drupal - Tue, 2024-09-17 02:54
Drupal's ongoing evolution has seen many innovations, with the latest being the introduction of Recipes with the “Recipes Initiative” in Drupal 10.3. Recipes, now part of the core of Drupal, represent a significant shift in how developers can automate the setup and configuration of Drupal sites. A Recipe explores the idea of “composibility” which will enable people to compose a Drupal website as per the need or at least a solid foundation. In this article, we’ll discuss Recipes in detail - what they are, why they’re fantastic, and how you can use them to create a perfectly crafted site. Get ready to cook up a storm with a foolproof recipe for Drupal success! But we already have Distributions! The concept of pre-configured packages is not new to Drupal. It was first introduced in Drupal 5 as Drupal distributions that include the Drupal core, along with additional modules, themes, and configurations aimed at serving a specific use case or industry. This concept made it easier for developers to quickly set up Drupal for specific applications like intranets, e-commerce sites, or government portals without starting from scratch. However, Drupal distributions offer a convenient way to get started with pre-configured setups, but they come with some drawbacks: Limited Flexibility: Predefined features and tightly integrated modules make customization difficult. Maintenance Complexity: Updating distributions can be challenging due to custom configurations, leading to potential compatibility issues. Dependency on Maintainers: Some distributions may be poorly maintained or abandoned, causing risks to security and updates. Performance Overhead: Unnecessary bundled modules can slow down the site and introduce vulnerabilities. Niche Focus: Distributions are often tailored to specific use cases, making it difficult to adapt if your needs change. Drupal Recipes solves problems with distributions by offering more modularity. Instead of coupling everything together, Recipes let you add only the specific features you need, avoiding the bloat of unnecessary modules. A Recipe in action To illustrate, imagine I need to set up an Event feature. For this, I will apply (Recipes are not installed but rather applied) an “Events Content-Type” Recipe which will set an Event content type with necessary attributes & fields, and configure views, metatags & paths for the Event contents. This will give me a solid foundational starting point to implement the feature where 70-80% of the basic setup and configurations are done by Recipes and on top of it I can make customizations to configure other settings as per my requirements. However, once applied, I am no longer dependent on the Recipe package anymore and it can be safely removed from my project keeping all the configured setup intact. Benefits of Drupal Recipes Modular Setup: Recipes allow for specific features or configurations to be added individually at any point in a project timeline.  Combine Multiple Recipes: Recipes can be easily combined or modified to fit specific use cases. This allows for a more customizable site-building experience, making it easier to adapt to changing requirements. No Lock-in: Unlike distributions, which are often tightly integrated, recipes give you more freedom to swap out or upgrade parts of your setup without being tied to a rigid structure. Composable: As mentioned above you can combine multiple recipes which means you can also compose Recipes with other recipes easily. If you want Event registration but also Commerce capabilities, you can easily create a new recipe that will apply the Event and Commerce recipes to be set up. What Recipes can do Install Modules and Themes: Recipes can automatically install necessary modules and themes. Apply Configurations: Recipes can apply both default and selective configurations provided by modules. Update Configurations: Recipes can update module configurations to fit your site's needs through' config actions'. Composable and Reusable: Recipes can be composed of other Recipes, making them highly modular and reusable across different projects. What Recipes cannot do Custom Code or Hooks: Recipes do not include custom PHP code, hooks, or API integrations. Module-Like Functionality: Unlike modules, Recipes cannot contain custom plugins, forms, or other typical Drupal module structures. Persistent Locking: Recipes do not persist after application; they set up the initial state and can be safely removed. Want to take full advantage of Drupal Recipes? Schedule a consultation with our experts and discover how our Drupal development services can help boost your site's growth! How to create and use a Recipe To get started, it is recommended that a new custom repository is created for the recipe. This will ensure that the recipe is version-controlled & managed efficiently to be used on other projects.  At the bare minimum, a recipe will require a “recipe.yml” file as the required file which will define the meta information like name, and description along with installations of modules/themes & configuration installations/updates. Apart from the “recipe.yml” a Recipe can also have the below optional items. The “config” directory holds the configuration entity yml files which will be installed when the Recipe is applied. The “content” directory holds the content entity yml files which will be created after the Recipe is applied. A “composer.json” file that allows the discoverability of Recipes via Composer. It will define any dependencies the Recipe might have on other modules or themes. A “README.md” can also be included to give a brief description of the Recipe which will allow users to better evaluate. So, the folder structure of a Recipe can look like this: recipe_name       ◦ recipe.yml       ◦ config           ▪ node.type.event.yml       ◦ content           ▪ node               • 43940d31-0106-46b4-ba32-39e511eb1f4a.yml       ◦ composer.json       ◦ README.md Dissecting the recipe.yml file A “recipe.yml” at minimal consists of “name” & “description” keys. Apart from that, it can include three different keys: Install packages with the “install” key which will specify the modules and/or themes to be installed when the Recipe is applied. If not already installed, Drupal will proceed to install each of the modules & themes specified in the list. install:   - address   - datetime_range   - media   - media_library   - geolocation_address   - geolocation_leaflet   - layout_builder   - metatag   - pathauto   - paragraphs   - smart_date Configuration related task under “config” key. This allows you to “import” configurations from a module in two ways     • Import all the configurations from a module with the “*” wildcard. This will import all the base configurations & optional configurations from a module.    • Import selective configuration from a module by specifying the list of configurations to be imported. config:   import:     media: "*"     node:       - views.view.contentWhen you want to update any active configuration which is being imported or any existing once, “action” comes into play which will allow you to update those configurations config:   actions:     metatag.settings:       simple_config_update:         entity_type_groups.node.event:           - basic           - advanced     workflows.workflow.editorial:       addNodeTypes:         - event Dependency on other recipes can be included under the “recipes” key which specifies the list of Recipes to be applied prior applying the current Recipe. recipes:   - core/recipes/image_media_type   - core/recipes/editorial_workflowApplying a Recipe Until reaching Phase 2 and a user interface (UI) for easier application, recipes are currently applied using Drupal core's PHP script. It can be executed with the following command in the CLI Drupal root: php core/scripts/drupal recipe recipes/recipe_nameAfter applying the recipe, it's also necessary to clear the caches to ensure the changes take effect. Applying a hosted Recipe If you Recipe has a “composer.json” file then it can be hosted on Packagist.org to make it discoverable and included in any project. However, to download the recipe in a “recipes” directory there are few changes which are required to be made in the project’s “composer.json” file composer require oomphinc/composer-installers-extender:2.0.1Update “installer-types” & “installer-paths” keys in the “composer.json” "installer-types": ["drupal-recipe"], "installer-paths": {   "web/recipes/{$name}": [ "type:drupal-recipe" ] }When you request Composer for a recipe, it will automatically place it in your project's “recipes” directory, similar to how it handles modules or themes. Once this is setup, you then you can use composer to require the package as usual.For this example, I am using a sample recipe which set ups an Event content type along with other configurations updates.  https://github.com/malabya/event_content_type/ composer require imalabya/event_content_type Once downloaded this can be applied with the Drupal core scripts php core/scripts/drupal recipe recipes/event_content_type Once the recipe is applied this will create an Event content type and enable Editirial workflow for the Event content type with default core configurations. This will also create 2 default contents for the Event content type to get started. Unpacking Recipes Even though Recipes do not lock in your site and can be safely replaced or removed once applied, you would want to maintain the dependencies in your project. When you request a Recipe, it will download all the dependencies mentioned in the Recipe’s “composer.json” file, but these dependencies are not copied/unpacked over into the project’s “composer.json” which will make it difficult to maintain or upgrade those dependencies. For this, use the composer plugin Drupal Recipe Unpack Composer Plugin to your project’s “composer.json” which allows the extraction of a packages dependencies into the project root composer and lock files for the sole purpose of implementation within Drupal recipes. Once the plugin is installed you can run the below command to unpack the dependencies composer unpack [organization/package-name]Final thoughts Recipes in Drupal 11 represent a powerful new tool for site builders and developers. They offer flexibility, modularity, and ease of maintenance that surpass traditional installation profiles and distributions. When it comes to creating a new Drupal site or adding new features, Recipes provides a streamlined, efficient way of managing the configuration. As Recipes continues to evolve, they promise to make Drupal site development more agile and responsive to changing needs, ultimately making Drupal a more accessible and powerful platform for all users. So do you want to cook from scratch or use Drupal Recipes? Your choice! Want to know how Drupal Recipes can enhance your project? Reach out to us to learn more about our Drupal development services and get started on your next big idea!
Categories: FLOSS Project Planets

Tryton News: Security Release for issues #13505 and #13506

Planet Python - Tue, 2024-09-17 02:00

Albert Cervera has found that trytond allows to execute reports for records that user has no read access and also for reports limited to a set of group that the user is not.

Impact

CVSS v3.0 Base Score: 4.3

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

There is no known workaround.

Resolution

All affected users should upgrade trytond to the latest version.

Affected versions per series:

  • trytond:
    • 7.2: <= 7.2.8
    • 7.0: <= 7.0.17
    • 6.0: <= 6.0.51

Non affected versions per series:

  • trytond:
    • 7.2: >= 7.2.9
    • 7.0: >= 7.0.18
    • 6.0: >= 6.0.52
Reference Concerns?

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

1 post - 1 participant

Read full topic

Categories: FLOSS Project Planets

Russ Allbery: Review: The Book That Broke the World

Planet Debian - Mon, 2024-09-16 22:57

Review: The Book That Broke the World, by Mark Lawrence

Series: Library Trilogy #2 Publisher: Ace Copyright: 2024 ISBN: 0-593-43796-9 Format: Kindle Pages: 366

The Book That Broke the World is high fantasy and a direct sequel to The Book That Wouldn't Burn. You should not start here. In a delightful break from normal practice, the author provides a useful summary of the previous volume at the start of this book to jog your memory.

At the end of The Book That Wouldn't Burn, the characters were scattered and in various states of corporeality after some major revelations about the nature of the Library and the first appearance of the insectile Skeer. The Book That Wouldn't Burn picks up where it left off, and there is a lot more contact with the Skeer, but my guess that they would be the next viewpoint characters does not pan out. Instead, we get a new group and a new protagonist: Celcha, whose sees angels who come to visit her brother.

I have complaints, but before I launch into those, I should say that I liked this book apart from the totally unnecessary cannibalism. (I'll get to that.) Livira is a bit sidelined, which is regrettable, but Celcha and her brother are interesting new characters, and both Arpix and Clovis, supporting characters in the first book, get some excellent character development. Similar to the first book, this is a puzzle box story full of world-building tidbits with intellectually-satisfying interactions. Lawrence elaborates and complicates his setting in ways that don't contradict earlier parts of the story but create more room and depth for the characters to be creative. I came away still invested in this world and eager to find out how Lawrence pulls the world-building and narrative threads together.

The biggest drawback of this book is that it's not new. My thought after finishing the first book of the series was that if Lawrence had enough world-building ideas to fill three books to that same level of density, this had the potential of being one of my favorite fantasy series of all time. By the end of the second book, I concluded that this is not the case. Instead of showing us new twists and complications the way the first book did throughout, The Book That Broke the World mostly covers the same thematic ground from some new angles. It felt like Lawrence was worried the reader of the first book may not have understood the theme or the world-building, so he spent most of the second book nailing down anything that moved.

I found that frustrating. One of the best parts of The Book That Wouldn't Burn was that Lawrence trusted the reader to keep up, which for me hit the glorious but rare sweet spot of pacing where I was figuring out the world at roughly the same pace as the characters. It surprised me in some very enjoyable ways. The Book That Broke the World did not surprise me. There are a few new things, which I enjoyed, and a few elaborations and developments of ideas, which I mostly enjoyed, but I saw the big plot twist coming at least fifty pages before it happened and found the aftermath more annoying than revelatory. It doesn't help that the plot rests on character misunderstandings, one of my least favorite tropes.

One of the other disappointments of this book is that the characters stop using the Library as a library. The Library at the center of this series is a truly marvelous piece of world-building with numerous fascinating features that are unrelated to its contents, but Livira used it first and foremost as a repository of books. The first book was full of characters solving problems by finding a relevant book and reading it.

In The Book That Broke the World, sadly, this is mostly gone. The Library is mostly reduced to a complicated Big Dumb Object setting. It's still a delightful bit of world-building, and we learn about a few new features, but I only remember two places where the actual books are important to the story. Even the book referenced in the title is mostly important as an artifact with properties unrelated to the words that it contains or to the act of reading it. I think this is a huge lost opportunity and something I hope Lawrence fixes in the last book of the trilogy.

This book instead focuses on the politics around the existence of the Library itself. Here I'm cautiously optimistic, although a lot is going to depend on the third book. Lawrence has set up a three-sided argument between groups that I will uncharitably describe as the libertarian techbros, the "burn it all down" reactionaries, and the neoliberal centrist technocrats. All three of those positions suck, and Lawrence had better be setting the stage for Livira to find a different path. Her unwillingness to commit to any of those sides gives me hope, but bringing this plot to a satisfying conclusion is going to be tricky. I hope I like what Lawrence comes up with, but it feels far from certain.

It doesn't help that he's started delivering some points with a sledgehammer, and that's where we get to the unnecessary cannibalism. Thankfully this is a fairly small part of the tail end of the book, but it was an unpleasant surprise that I did not want in this novel and that I don't think made the story any better.

It's tempting to call the cannibalism gratuitous, but it does fit one of the main themes of this story, namely that humans are depressingly good at using any rule-based object in unexpected and nasty ways that are contrary to the best intentions of the designer. This is the fundamental challenge of the Library as a whole and the question that I suspect the third book will be devoted to addressing, so I understand why Lawrence wanted to emphasize his point. The reason why there is cannibalism here is directly related to a profound misunderstanding of the properties of the library, and I detected an echo of one of C.S. Lewis's arguments in The Last Battle about the nature of Hell.

The problem, though, is that this is Satanic baby-killerism, to borrow a term from Fred Clark. There are numerous ways to show this type of perversion of well-intended systems, which I know because Lawrence used other ones in the first book that were more subtle but equally effective. One of the best parts of The Book That Wouldn't Burn is that there were few real villains. The conflict was structural, all sides had valid perspectives, and the ethical points of that story were made with some care and nuance.

The problem with cannibalism as it's used here is not merely that it's gross and disgusting and off-putting to the reader, although it is all of those things. If I wanted to read horror, I would read horror novels. I don't appreciate surprise horror used for shock value in regular fantasy. But worse, it's an abandonment of moral nuance. The function of cannibalism in this story is like the function of Satanic baby-killers: it's to signal that these people are wholly and irredeemably evil. They are the Villains, they are Wrong, and they cease to be characters and become symbols of what the protagonists are fighting. This is destructive to the story because it's designed to provoke a visceral short-circuit in the reader and let the author get away with sloppy story-telling. If the author needs to use tactics like this to point out who is the villain, they have failed to set up their moral quandary properly.

The worst part is that this was entirely unnecessary because Lawrence's story-telling wasn't sloppy and he set up his moral quandary just fine. No one was confused about the ethical point here. I as the reader was following without difficulty, and had appreciated the subtlety with which Lawrence posed the question. But apparently he thought he was too subtle and decided to come back to the point with a pile-driver. I think that seriously injured the story. The ethical argument here is much more engaging and thought-provoking when it's more finely balanced.

That's a lot of complaints, mostly because this is a good book that I badly wanted to be a great book but which kept tripping over its own feet. A lot of trilogies have weak second books. Hopefully this is another example of the mid-story sag, and the finale will be worthy of the start of the story. But I have to admit the moral short-circuiting and the de-emphasis of the actual books in the library has me a bit nervous. I want a lot out of the third book, and I hope I'm not asking this author for too much.

If you liked the first book, I think you'll like this one too, with the caveat that it's quite a bit darker and more violent in places, even apart from the surprise cannibalism. But if you've not started this series, you may want to wait for the third book to see if Lawrence can pull off the ending.

Followed by The Book That Held Her Heart, currently scheduled for publication in April of 2025.

Rating: 7 out of 10

Categories: FLOSS Project Planets

Dirk Eddelbuettel: nanotime 0.3.10 on CRAN: Update

Planet Debian - Mon, 2024-09-16 20:58

A minor update 0.3.10 for our nanotime package is now on CRAN. nanotime relies on the RcppCCTZ package (as well as the RcppDate package for additional C++ operations) and offers efficient high(er) resolution time parsing and formatting up to nanosecond resolution, using the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations.

This release updates one S4 methods to very recent changes in r-devel for which CRAN had reached out. This concerns the setdiff() method when applied to two nanotime objects. As it only affected R 4.5.0, due next April, if rebuilt in the last two or so weeks it will not have been visible to that many users, if any. In any event, it now works again for that setup too, and should be going forward.

We also retired one demo function from the very early days, apparently it relied on ggplot2 features that have since moved on. If someone would like to help out and resurrect the demo, please get in touch. We also cleaned out some no longer used tests, and updated DESCRIPTION to what is required now. The NEWS snippet below has the full details.

Changes in version 0.3.10 (2024-09-16)
  • Retire several checks for Solaris in test suite (Dirk in #130)

  • Switch to Authors@R in DESCRIPTION as now required by CRAN

  • Accommodate R-devel change for setdiff (Dirk in #133 fixing #132)

  • No longer ship defunction ggplot2 demo (Dirk fixing #131)

Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository – and all documentation is provided at the nanotime documentation 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.

Categories: FLOSS Project Planets

Oliver Davies' daily list: Next week is DrupalCon Barcelona

Planet Drupal - Mon, 2024-09-16 20:00

Next week is DrupalCon in Barcelona.

I'm not speaking this year but if you're there and want to discuss automated testing, test-driven development, static analysis, Sculpin, Tailwind CSS, Nix, or anything else, I'll be there all week and would love to meet up and chat.

Categories: FLOSS Project Planets

Open Source AI Definition – Weekly update september 16

Open Source Initiative - Mon, 2024-09-16 19:38
Week 37 summary  Endorse the Open Source AI Definition Recommended Resources: US Copyright Office Guidance on TDM
  • @mjbommar encourages reviewing the U.S. Copyright Office’s guidance on text and data mining (TDM) exceptions, which provides clear explanations and limitations, especially focusing on non-commercial, scholarly, and teaching uses. He emphasizes that the TDM guidance operates within narrow parameters that are often misunderstood or overlooked.
Proposal to handle Data Openness in the Open Source AI definition [RFC]
  • @quaid proposes adding nuance to the Open Source AI (OSAI) Definition by introducing two designations: OSAI D+ (with open data) and OSAI D- (without open data, due to legitimate reasons beyond the creator’s control). He suggests using a dataset certificate of origin (dataset DCO) for self-verification to ensure compliance.
  • @kjetilk agrees that verification is key but questions whether data information alone is sufficient for verification. He highlights that verifying rights to the data may not always be possible.
  • @stefano appreciates the quadrant system’s clarity and confirms @quaid’s proposal for OSAI D- to be reserved for those with legitimate reasons for not sharing data.
  • @thesteve0 expresses skepticism about broadening the “Open Source” label. He argues that without access to both data and code, AI models cannot truly be Open Source and suggests labeling such models as “open weights” instead.
  • @shujisado notes the importance of data access in AI, pointing out that OSAID requires detailed information about how data is sourced, including provenance and selection criteria. He also discusses potential legal and ethical reasons for not sharing datasets.
  • @Shamar raises concerns about “openwashing” in AI, where developers might distribute a model with a different dataset, undermining trust. He argues that distinguishing between OSAI D+ and D- risks legal complications for derivative works, suggesting that models without open data should not be considered truly open.
  • @zack supports the idea of a tiered system (D+ and D-) as an improvement over the current situation, as it incentivizes progress from D- to D+. He is skeptical about verifiability but sees potential in the branding aspect of the proposal.
Welcome diverse approaches to training data within a unified Open Source AI Definition
  • @stefano asks @arandal about suggested edits, which include renaming data as “source data,” allowing open-source AI developers to require downstream modifications with open data, and permitting downstream developers to use open data to fine-tune models trained on non-public data. He further asks if arandal compares training data to model weights as source code is to binary code.
  • @shujisado agrees with @stefano and points out that while many interpret OSD-compliant licenses to include CC4 and CC0, OSI has not officially evaluated Creative Commons licenses for compliance. He highlights concerns about CC0’s patent defense, which could be crucial for datasets.
  • @mjbommar echoes the concerns about patent defense, noting it as a critical issue in both software and data licensing.
  • @Shamar supports the first two suggestions but argues that models trained on non-public data cannot meet an “Open Source AI” definition, as they limit the freedom to study and modify, which are core principles of Open Source.
On the current definition of Open Source AI and the state of the data commons
  • @nick shares an article by Nathan Lambert, reviewed by key figures in the Open Source AI space, discussing the challenges of training data and the current Open Source AI definition. @Percy Liang (on X) view is highlighted, where he suggests that releasing an entire dataset is neither sufficient nor necessary for Open Source AI. He emphasizes the need for detailed code of the data processing pipeline for transparency, beyond just releasing the dataset.
  • @shujisado discusses the legal nuances of using U.S. government documents in AI training, emphasizing that while they may be used in the U.S., legal complications arise in other jurisdictions.
  • @Shamar stresses that Open Source AI should provide all the necessary data and processing information to recreate a system, otherwise, calling it Open Source is “open washing.”
[RFC] Separating concerns between Source Data and Processing Information
  • @Shamar proposes a clearer distinction between “source data” and “processing information” in the Open Source AI definition to ensure transparency and reproducibility. He suggests source data should be publicly available under the same terms that allowed its original use, while the process used to train the system should be shared under an Open Source license. His formulation aims to prevent loopholes that could lead to open-washing and emphasizes the importance of granting all four freedoms (study, modify, distribute, and use) to qualify as Open Source AI.
  • @nick disagrees, arguing that @Shamar proposal misunderstands the difference between the rights to use data for training and the rights to distribute it. He also challenges the claim that exact replication of AI systems can be guaranteed, even with access to the same data.
Open Source AI Definition Town Hall – September 13, 2024

Categories: FLOSS Research

Nonprofit Drupal posts: September Drupal for Nonprofits Chat

Planet Drupal - Mon, 2024-09-16 17:27

Join us THURSDAY, September 19 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits.  Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone. 

  • Join the call: https://us02web.zoom.us/j/81817469653

    • Meeting ID: 818 1746 9653
      Passcode: 551681

    • One tap mobile:
      +16699006833,,81817469653# US (San Jose)
      +13462487799,,81817469653# US (Houston)

    • Dial by your location:
      +1 669 900 6833 US (San Jose)
      +1 346 248 7799 US (Houston)
      +1 253 215 8782 US (Tacoma)
      +1 929 205 6099 US (New York)
      +1 301 715 8592 US (Washington DC)
      +1 312 626 6799 US (Chicago)

    • Find your local number: https://us02web.zoom.us/u/kpV1o65N

  • Follow along on Google Docs: https://nten.org/drupal/notes

View notes of previous months' calls.

Categories: FLOSS Project Planets

drunomics: Why we don't use GraphQL

Planet Drupal - Mon, 2024-09-16 15:38
Why we don't use GraphQL wolfgang.ziegler Mon, 09/16/2024 - 21:38 Exploring drawbacks of GraphQL in decoupled Drupal, including complexity, loose contracts, performance issues, and security concerns. RESTful alternatives are discussed. Body

At drunomics we are building decoupled Drupal sites for more than five years. During this time, GraphQL has always been a popular choice for decoupled Drupal sites among professional or enterprise projects, thanks to the well maintained GraphQL contrib module. Still, I've vetted against using GraphQL for various enterprise projects, even though sometimes it was appealing to customers. In this blog post, I'd like to summarize why we don't use GraphQL:

General complexity

GraphQL is not only a new query language to learn for both frontenders and backenders, moreover the backend has to support any kind of queries the frontenders make. On the frontend side of things, additional libraries and tooling is needed to handle the protocol.

Loose contracts

GraphQL gives a lot of power to frontend developers, but that comes with a huge price: No defined or a very loosely defined contract, i.e. the data model or more specifically the GraphQL schema layered on top. Based upon this loose contract the frontend may compose any kind of queries, which the backend has to support. What leads to the next point:

Complex queries

When the backend is exposing the Drupal data schema directly, potentiallly a lot of things become leaked unwanted and changing things might became hard, because: Who knows what data properties the frontend uses and queries for? It's quite hard to optimize for every use-case.

However, the backend may compose it's own GraphQL schema and provide exactly the data model as needed by the client, the frontend. That's indeed, a great option to have, but it requires additional work and code to translate between the schema and the real data model behind. It makes it possible to change the underlying data model and schema mapping, while staying with the same or compatible GraphQL output and schema. But is that code performing the mapping performant enough? Does it work correctly? That's quite hard to tell without knowing exactly the queries one has to optimize and test for. So things are or become complex.

Performance

First of all, GraphQL is bad for caching since it makes use of POST requests. The typical work-around is to use shortened, hashed queries and to access them via GET requests, what can help to mitigate the issue. But this comes at the cost of tying the deployed frontend and backend versions, thus increasing overall system and deployment complexity. That way, the main GraphQL advantage - flexibility at the frontend - gets lost. So not an easy or great compromise to make.

Client driven data fetching

With GraphQL, the web browser (or generally the client) sends a query to the server, specifying the exact data it needs. While this can help to reduce payload size, it puts the client in the "driving seat". That often leads to additional round trips being required: Based upon the first request, often additional data is required for rendering it. This additional data often has to be fetched in additional requests, thus requiring another or multiple round-trips to the server and thus increasing latency.

In contrast, when the server is in the "driving seat", it may efficiently do all queries and resolve additional data, and then send the resulting data over the slower network once.

Security

GraphQL queries can expose sensitive data if not properly secured. This can be mitigated by implementing proper authentication and authorization mechanisms. However, this can get very complex easily: Since the server does not know the queries needed by the client, it needs to handle every possible combination a client may request. Unfortunately, it's commonly rather easy for hackers to purposely write computationally very expensive (GraphQL) queries and to send them to the server, thus opening the door for DDOS or even DOS attacks.

Besides that, due to the complexity of the backend having to cover all possible combinations, the danger for data leaking accidentially becomes rather high.

The conclusion

GraphQL comes with a couple of issues, which are - as usual - solvable. That's a price one might want to pay in certain situations, if the benefits are worth it. Thus, is using GraphQL a good idea? As so often, it depends. But in my experience, it's more often not, than it is.

Alternatives are RESTful

The typical alternative to GraphQL is a RESTful API. As usual, with Drupal there are a couple of good options:

  • Drupal comes with the JSON-API out-of-the box, which is a great feature to have. While it's good fit in certain situations, it also faces some of the issues mentioned above, most notable "Client driven data fetching" and "Loose contracts".
  • Developers may use Drupal's API to provide custom-coded RESTful endpoints for the client. That addresses all mentioned concerns, but requires backend development time for every feature and most notable careful planing. This comes with the downside of frontend developers loosing the flexibility. (By the way, this is what GraphQL is loved for!)
  • Configurable RESTful endpoints. In order to improve the development process and gain flexibility in the frontend, we developed a solution for providing custom RESTful endpoints that are configurable via Drupal, by frontend developers. For that, we improved the Custom Elements module, which is part of Lupus Decoupled Drupal, such that it integrates with Drupal's configuration sytem and provides an UI for customizing output by entity view-mode. That way, in many situations, we can tick all the boxes, while enabling the frontend developer to work efficiently. I'll share more details about the new Custom Elements UI in a dedicated blog post later this week.
Categories: FLOSS Project Planets

FSF Events: Free Software Directory meeting on IRC: Friday, September 20, starting at 12:00 EDT (16:00 UTC)

GNU Planet! - Mon, 2024-09-16 14:12
Join the FSF and friends on Friday, September 20 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.
Categories: FLOSS Project Planets

Talking Drupal: Talking Drupal #467 - Config Actions System

Planet Drupal - Mon, 2024-09-16 14:00

Today we are talking about The Config Actions System, What it does, and how it helps with Drupal Recipes with guests Alex Pott and Adam Globus-Hoenich. We’ll also cover the Events recipe as our module of the week.

For show notes visit: www.talkingDrupal.com/467

Topics
  • Explain Config Actions
  • Is this related to the Actions UI
  • How are config actions used in Drupal
  • How will the average user interact with Config Actions
  • What does non-desctructive mean
  • Where did the Config Action system come from
  • Future of the Config Action system
  • How can people help out
  • How does the Config Action system help with Drupal CMS
Resources Guests

Alex Pott - alexpott Adam Globus-Hoenich - phenaproxima

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Nate Dentzau - dentzau.com nathandentzau

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

  • Brief description:
    • Have you ever wanted to set up and configure a robust events system in your Drupal website, in just a few seconds? There’s a recipe for that.
  • Module name/project name:
  • Brief history
    • How old: originally created in Mar 2013 as a distribution, but reborn as a recipe in July 2024
    • Versions available: 1.0.0-alpha3, compatible with Drupal 10.3 and 11
  • Maintainership
    • Actively maintained
    • Security coverage? - no stable release
    • Documentation in the works
    • Number of open issues: 1 open issue, which is a bug
  • Usage stats: not tracked for recipes
  • Maintainer(s): mandclu
  • Module features and usage
    • Listeners probably won’t be surprised to hear that Smart Date is at the heart of what you’ll get when you apply the Events recipe
    • You will have an Event content type, and a view to list upcoming and past events
    • The recipe will also set up add-to-calendar links on your event page, making it easy for your site visitors to be reminded of when your event will take place
    • There are companion recipes to add a calendar view, to be able to associate locations (with maps), and to add event registration
    • A modified version of the Events recipe has already been integrated into Drupal CMS, so it will be even easier to apply for a site based on that
    • Internally it makes use of the createIfNotExists and setComponents config actions, which is why I thought it would be relevant to today’s discussion
Categories: FLOSS Project Planets

mark.ie: Live Previews for LocalGov Microsites Design Changes

Planet Drupal - Mon, 2024-09-16 11:48

I had great fun today expanding what was a proof-of-concept module from last year into a very usable live preview module for LGD Microsites.

Categories: FLOSS Project Planets

Plasma 6.2 Beta in KDE neon Testing Edition

Planet KDE - Mon, 2024-09-16 11:25

Back from the fun of Akademy in Würzburg we can now get to the important task of testing Plasma 6.2 beta. It’s now in KDE neon testing edition which we build from the Git branches which will be used to make the 6.2 final release in 2.5 weeks time. Grab it now or if you don’t have a machine to install it on you can try the Docker images using the simple command `neondocker -p -e testing`.

Categories: FLOSS Project Planets

Real Python: Using Python's pip to Manage Your Projects' Dependencies

Planet Python - Mon, 2024-09-16 10:00

The standard package manager for Python is pip. It allows you to install and manage packages that aren’t part of the Python standard library. If you’re looking for an introduction to pip, then you’ve come to the right place!

In this tutorial, you’ll learn how to:

  • Set up pip in your working environment
  • Fix common errors related to working with pip
  • Install and uninstall packages with pip
  • Manage projects’ dependencies using requirements files

You can do a lot with pip, but the Python community is very active and has created some neat alternatives to pip. You’ll learn about those later in this tutorial.

Get Your Cheat Sheet: Click here to download a free pip cheat sheet that summarizes the most important pip commands.

Getting Started With pip

So, what exactly does pip do? pip is a package manager for Python. That means it’s a tool that allows you to install and manage libraries and dependencies that aren’t distributed as part of the standard library. The name pip was introduced by Ian Bicking in 2008:

I’ve finished renaming pyinstall to its new name: pip. The name pip is [an] acronym and declaration: pip installs packages. (Source)

Package management is so important that Python’s installers have included pip since versions 3.4 and 2.7.9, for Python 3 and Python 2, respectively. Many Python projects use pip, which makes it an essential tool for every Pythonista.

The concept of a package manager might be familiar to you if you’re coming from another programming language. JavaScript uses npm for package management, Ruby uses gem, and the .NET platform uses NuGet. In Python, pip has become the standard package manager.

Finding pip on Your System

The Python installer gives you the option to install pip when installing Python on your system. In fact, the option to install pip with Python is checked by default, so pip should be ready for you to use after installing Python.

Note: On some Linux (Unix) systems like Ubuntu, pip comes in a separate package called python3-pip, which you need to install with sudo apt install python3-pip. It’s not installed by default with the interpreter.

You can verify that pip is available by looking for the pip3 executable on your system. Select your operating system below and use your platform-specific command accordingly:

Windows PowerShell PS> where pip3 Copied!

The where command on Windows will show you where you can find the executable of pip3. If Windows can’t find an executable named pip3, then you can also try looking for pip without the three (3) at the end.

Shell $ which pip3 Copied!

The which command on Linux systems and macOS shows you where the pip3 binary file is located.

On Windows and Unix systems, pip3 may be found in more than one location. This can happen when you have multiple Python versions installed. If you can’t find pip in any location on your system, then you may consider reinstalling pip.

Instead of running your system pip directly, you can also run it as a Python module. In the next section, you’ll learn how.

Running pip as a Module

When you run your system pip directly, the command itself doesn’t reveal which Python version pip belongs to. This unfortunately means that you could use pip to install a package into the site-packages of an old Python version without noticing. To prevent this from happening, you should run pip as a Python module:

Shell $ python -m pip Copied!

Notice that you use python -m to run pip. The -m switch tells Python to run a module as an executable of the python interpreter. This way, you can ensure that your system default Python version runs the pip command. If you want to learn more about this way of running pip, then you can read Brett Cannon’s insightful article about the advantages of using python -m pip.

Note: Depending on how you installed Python, your Python executable may have a different name than python. You’ll see python used in this tutorial, but you may have to adapt the commands to use something like py or python3 instead.

Sometimes you may want to be more explicit and limit packages to a specific project. In situations like this, you should run pip inside a virtual environment.

Using pip in a Python Virtual Environment Read the full article at https://realpython.com/what-is-pip/ »

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

Categories: FLOSS Project Planets

Pages