Golems GABB: Improving Page Loading Speed in Drupal with Different Caching Solutions

Planet Drupal - Mon, 2024-02-05 05:12
Improving Page Loading Speed in Drupal with Different Caching Solutions Editor Mon, 02/05/2024 - 12:12

Fun fact. Drupal was started in 2001 — two years before WordPress was released. According to W3Techs, this CMS powers 1.1% of all websites, from blogs to e-commerce and government sites, holding a 1.6% market share.
Building a website with Drupal is a good idea. But remember: a poorly optimized Drupal site is vulnerable, has lower response times, and results in database delays. When talking about its performance optimization, the tricks include different architectural changes, modes of caching, and other ways to speed up website load time. 

Categories: FLOSS Project Planets

LN Webworks: Mastering PHP Debugging: A Guide to Xdebug in Lando & DDEV for Drupal

Planet Drupal - Mon, 2024-02-05 05:03

Did you know that the first-ever computer bug wasn't a piece of software code, but an actual moth? Now, let's talk about something related but not quite as buggy – website development.

Debugging is like fixing problems in a website's code. It's important because it helps Drupal developers find and solve issues, making the website work better. To do this, you need the right tools. One handy tool for PHP (a programming language often used in web development) is XDebug.

In this article, we’ll share the steps and things you need to know to set up PHP debugging using XDebug. We'll focus on using Lando and DDEV setups for Drupal. And to make things even better, we'll be using the VS Code IDE (that stands for Integrated Development Environment). Let’s get started! 

A Close Look at XDebug

XDebug is a powerful debugger that makes it easier for PHP developers to create a smooth functioning website. Here are some core features of it: 

Categories: FLOSS Project Planets


Planet Drupal - Mon, 2024-02-05 02:59

Dear Readers,

There is a philosophy popularised as "Open Education" which is based on the way people produce, share, and build on knowledge. The Open Education Consortium states that, 

"sharing is probably the most basic characteristic of education: education is sharing knowledge, insights, and information with others, upon which new knowledge, skills, ideas and understanding can be built."

Open education and open-source software converge on the fundamental belief in the power of openness, collaboration, and accessibility. They share a philosophy centered on democratizing knowledge and technology by removing barriers to access, promoting transparency, and fostering community-driven development. In both domains, open or not, individuals should be encouraged to actively participate, contribute, and collaborate, whether in creating educational resources or improving software functionality.

It is no secret that the educational industry is one of the largest adopters of Drupal, while scrounging through Drupal.org, one can find a statistic stating that 71% of the top hundred universities use Drupal. Put forward by Kevin Reynen (University of Colorado), we at The DropTimes headed by Vimal Joseph embarked on a project to validate and substantiate this claim with proper evidence. The analysis resulted in a strong correlation between Drupal and university rankings. Notably, 80% of the top 100 universities utilize Drupal on at least one of their websites.

Find the list of selected universities for the analysis by The DropTimes here and also Vimal Joseph shares the journey behind this conclusion for the readers to understand and contribute relevant information.

In the previous week, I also had the opportunity to publish an interview featuring Boyan Borisov,  VP of Digital Solutions Europe at FFW. In an email correspondence, Boyan Borisov shared his journey of becoming a Drupal enthusiast and probed into transitioning through different roles at FFW. The interview also discusses Boyan's involvement with the Drupal Community, the benefits and challenges of transitioning from individual Drupal sites to a unified multi-brand ecosystem using Drupal Multisite, and most importantly his thoughts on the future of Drupal. For a detailed read refer to, "Drupal's Future Excites and Warrants Consideration: Boyan Borisov."

Michael Richardson emerged as the victor in The Event Organizers Working Group Elections. Richardson shared his gratitude for the opportunity with The DropTimes and remarks that "Two Michaels are better than one," reflecting the enthusiasm surrounding this recent development.  

Categories: FLOSS Project Planets

Python GUIs: QLineEdit — A Simple Text Input Widget

Planet Python - Mon, 2024-02-05 01:00

The QLineEdit class is a versatile tool for single-line text input. The widget facilitates text manipulation by supporting insertion, deletion, selection, and cut-copy-paste operations natively. You can use line edits when you need to accept text input from your users in a PyQt/PySide application.

The widget is highly customizable. You can set it up to include placeholder text, input masks, input validators, and more. It also supports many keyboard shortcuts out of the box and is able to process custom ones. This feature opens an opportunity to enhance user input speed and efficiency.

In this article, you will learn the basics of using QLineEdit by going through its most commonly used features and capabilities.

Table of Contents Creating Line Edit Widgets With QLineEdit

A line edit allows the user to enter and edit a single line of plain text with a useful collection of editing functionalities, such as insertion, deletion, selection, cut-copy-paste, and drag-and-drop operations.

If you've used PyQt or PySide to create GUI applications in Python, then it'd be likely that you already know about the QLineEdit class. This class allows you to create line edits in your graphical interfaces (GUI) quickly.

The QLineEidt class provides two different constructors that you can use to create line edits according to your needs:

Constructor Description QLineEdit(parent: QWidget = None) Constructs a line edit with a parent widget but without text QLineEdit(text: str, parent: QWidget = None) Constructs a line edit with default text and a parent widget

The parent widget would be the window or dialog where you need to place the line edit. The text can be a default text that will appear in the line edit when you run the application.

To illustrate how to use the above constructors, we can code a demo example:

python from PyQt6.QtWidgets import QApplication, QLineEdit, QVBoxLayout, QWidget class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("QLineEdit Constructors") self.resize(300, 100) # Line edit with a parent widget top_line_edit = QLineEdit(parent=self) # Line edit with a parent widget and a default text bottom_line_edit = QLineEdit( "Hello! This is a line edit.", parent=self ) layout = QVBoxLayout() layout.addWidget(top_line_edit) layout.addWidget(bottom_line_edit) self.setLayout(layout) app = QApplication([]) window = Window() window.show() app.exec()

In this example, we first do the required imports and then define the Window class inheriting from QWidget. Inside Window, we create two QLineEdit widgets.

To create the first line edit, we use the first constructor of QLineEdit, passing only a parent widget. For the second line editor, we use the second constructor, which requires the parent widget and a default text. Note that the text is a regular Python string.

Save the code to a file called constructors.py file and run it from your command line. You'll get a window that looks something like this:

Standard window showing our two line edits.

The first line edit has no text. In most cases, this is how you would create your line edits because they're designed for accepting input. If you'd like to just display some text, then you can use a QLabel widget instead. The second line edit displays the text that you passed to the constructor.

Both line edits are ready for accepting input text. Note that you can use all the following keyboard shortcuts to optimize your text input process:

Keys Action Left Arrow Moves the cursor one character to the left Shift+Left Arrow Moves and selects text one character to the left Right Arrow Moves the cursor one character to the right Shift+Right Arrow Moves and selects text one character to the right Home Moves the cursor to the beginning of the line End Moves the cursor to the end of the line Backspace Deletes the character to the left of the cursor Ctrl+Backspace Deletes the word to the left of the cursor Delete Deletes the character to the right of the cursor Ctrl+Delete Deletes the word to the right of the cursor Ctrl+A Select all Ctrl+C Copies the selected text to the clipboard Ctrl+Insert Copies the selected text to the clipboard Ctrl+K Deletes to the end of the line Ctrl+V Pastes the clipboard text into the line edit Shift+Insert Pastes the clipboard text into the line edit Ctrl+X Deletes the selected text and copies it to the clipboard Shift+Delete Deletes the selected text and copies it to the clipboard Ctrl+Z Undoes the last operation Ctrl+Y Redoes the last undone operation

That's a lot of shortcuts! This table is just a sample of all the features that the QLineEdit class provides out of the box.

In addition to these keyboard shortcuts, the QLineEdit class provides a context menu that you can trigger by clicking on a line edit using the right button of your mouse:

QLineEdit with a context menu visible.

The built-in context menu provides basic edition options, such as cut, copy, paste, and delete. It also has options for undoing and redoing edits, and for selecting all the content of a given line edit.

Creating Non-Editable Line Edits

Sometimes, we need to make a line edit non-editable. By default, all line edits are editable because their main use case is to provide text input for the user. However, in some situations, a non-editable line edit can be useful.

For example, say that you're creating a GUI application that generates some recovery keys for the users. The user must be able to copy the key to a safe place so that they can use it to recover access if they forget their password. In this situation, creating a non-editable line edit can provide a suitable solution.

To make a line edit read-only, we can use the readOnly property and its setter method setReadOnly() as in the following example:

python import secrets from PyQt6.QtWidgets import ( QApplication, QLabel, QLineEdit, QVBoxLayout, QWidget, ) class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Non-editable QLineEdit") self.resize(300, 100) non_editable_line_edit = QLineEdit(parent=self) non_editable_line_edit.setReadOnly(True) non_editable_line_edit.setText(secrets.token_hex(16)) layout = QVBoxLayout() layout.addWidget(QLabel(parent=self, text="Your secret key:")) layout.addWidget(non_editable_line_edit) self.setLayout(layout) app = QApplication([]) window = Window() window.show() app.exec()

In this example, we create a non-editable line edit by using the setReadOnly() method. When we set the readOnly property to True, our line edit won't accept editions. It'll only allow us to select and copy its content.

Go ahead and run the application from your command line to explore how this line edit works. You'll get a window like the following:

A read-only line edit with editing disabled.

If you play a bit with this line edit, you'll soon discover that you can't change its text. You'll also note that the options in the context menu are now limited to Copy and Select All.

Creating Line Edits for Passwords

Another cool feature of the QLineEdit class is that it allows you to create text input for passwords. This can be pretty convenient for those applications that manage several users, and each user needs to have access credentials.

You can create line edits for passwords by using the echoMode() method. This method takes one of the following constants as an argument:

Constant Value Description QLineEdit.EchoMode.Normal 0 Display characters as you enter them. QLineEdit.EchoMode.NoEcho 1 Display no characters when you enter them. QLineEdit.EchoMode.Password 2 Display platform-dependent password mask characters instead of the characters you enter. QLineEdit.EchoMode.PasswordEchoOnEdit 3 Display characters as you enter them while editing. Display characters as the Password mode does when reading.

The Normal mode is the default. The NoEcho mode may be appropriate for critical passwords where even the length of the password should be kept secret. The Password mode is appropriate for most password use cases, however PasswordEchoOnEdit can be used instead if you need to give users some confirmation of what they are typing.

Here's a sample app that shows a user and password form:

python from PyQt6.QtWidgets import ( QApplication, QFormLayout, QLineEdit, QWidget, ) class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Password QLineEdit") self.resize(300, 100) username_line_edit = QLineEdit(parent=self) password_line_edit = QLineEdit(parent=self) password_line_edit.setEchoMode(QLineEdit.EchoMode.Password) layout = QFormLayout() layout.addRow("Username:", username_line_edit) layout.addRow("Password:", password_line_edit) self.setLayout(layout) app = QApplication([]) window = Window() window.show() app.exec()

In this example, you call setEchoMode() on the password_line_edit widget using the Password mode as an argument. When you run this code from your command line, you get the following window on your screen:

Window with a username and password line edit.

The username_line_edit line edit is in Normal mode, so we can see the characters as we type them in. In contrast, the Password line edit is in Password mode. In this case, when we enter a character, the line edit shows the platform's character for passwords.

Manipulating the Input in a Line Edit

You can change the text of a line edit using the setText() or insert() methods. You can retrieve the text with the text() method. However, these are not the only operations that you can perform with the text of a line edit.

The following table shows a summary of some of the most commonly used methods for text manipulation in line edits:

Method Description setText(text) Sets the text of a line edit to text, clears the selection, clears the undo/redo history, moves the cursor to the end of the line, and resets the modified property to false. insert(text) Deletes any selected text, inserts text, and validates the result. If it is valid, it sets it as the new contents of the line edit. clear() Clears the contents of the line edit. copy() Copies the selected text to the clipboard. cut() Copies the selected text to the clipboard and deletes it from the line edit. paste() Inserts the clipboard's text at the cursor position, deleting any selected text. redo() Redoes the last operation if redo is available. Redo becomes available once the user has performed one or more undo operations on text in the line edit. undo() Undoes the last operation if undo is available. Undo becomes available once the user has modified the text in the line edit. selectAll() Selects all the text and moves the cursor to the end.

You can use any of these methods to manipulate the text of a line edit from your code. Consider the following example where you have two line edits and two buttons that take advantage of some of the above methods to copy some text from one line edit to the other:

python from PyQt6.QtWidgets import ( QApplication, QGridLayout, QLabel, QLineEdit, QPushButton, QWidget, ) class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Copy and Paste") self.resize(300, 100) self.source_line_edit = QLineEdit(parent=self) self.source_line_edit.setText("Hello, World!") self.dest_line_edit = QLineEdit(parent=self) copy_button = QPushButton(parent=self, text="Copy") paste_button = QPushButton(parent=self, text="Paste") copy_button.clicked.connect(self.copy) paste_button.clicked.connect(self.paste) layout = QGridLayout() layout.addWidget(self.source_line_edit, 0, 0) layout.addWidget(copy_button, 0, 1) layout.addWidget(self.dest_line_edit, 1, 0) layout.addWidget(paste_button, 1, 1) self.setLayout(layout) def copy(self): self.source_line_edit.selectAll() self.source_line_edit.copy() def paste(self): self.dest_line_edit.clear() self.dest_line_edit.paste() app = QApplication([]) window = Window() window.show() app.exec()

In this example, we create two line edits. The first one will hold some sample text. The second line edit will receive the text. Then, we create two buttons and connect their clicked signals to the copy() and paste() slots.

Inside the copy() method we first select all the text from the source line edit. Then we use the copy() method to copy the selected text to the clipboard. In paste(), we call clear() on the destination line edit to remove any previous text. Then, we use the paste() method to copy the clipboard's content.

Go ahead and run the application. You'll get the following window on your screen:

QLineEdit with Copy & Paste buttons attached to handlers.

Once you've run the app, then you can click the Copy button to copy the text in the first line edit. Next, you can click the Paste button to paste the copied text to the second line edit. Go ahead and give it a try!

Aligning and Formatting the Text in a Line Edit

You can also align and format the text in a line edit. For example, for text alignment, you can use the setAlignment() method with one or more alignment flags. Some of the most useful flags that you can find in the Qt.AlignmentFlag namespace includes the following:

Flag Description AlignLeft Aligns with the left edge. AlignRight Aligns with the right edge. AlignHCenter Centers horizontally in the available space. AlignJustify Justifies the text in the available space. AlignTop Aligns with the top. AlignBottom Aligns with the bottom. AlignVCenter Centers vertically in the available space. AlignCenter Centers in both dimensions.

If you want to apply multiple alignment flags to a given line edit, you don't have to call setAlignment() multiple times. You can just use the bitwise OR operator (|) to combine them. Consider the following example:

python from PyQt6.QtCore import Qt from PyQt6.QtWidgets import QApplication, QLineEdit class Window(QLineEdit): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Aligning Text") self.resize(300, 100) self.setText("Hello, World!") self.setAlignment(Qt.AlignmentFlag.AlignCenter) app = QApplication([]) window = Window() window.show() app.exec()

In this example, we use a QLineEdit as the only component of our app's GUI. Using the setAlignment() method, we center the "Hello, World!" message in both directions, horizontally and vertically. To do this, we use the AlignCenter flag. Here's what the app looks like:

QLineEdit with text alignment set.

Go ahead and play with other flags to see their effect on the text alignment. Use the | bitwise operator to combine several alignment flags.

Line edits also have a textMargins property that you can tweak to customize the text alignment using specific values. To set margin values for your text, you can use the setTextMargins() method, which has the following signatures:

Method Description setTextMargins(left, top, right, bottom) Sets the margins around the text to have the sizes left, top, right, and bottom. setTextMargins(margins) Sets the margins around the text using a QMargins object.

The first signature allows you to provide four integer values as the left, top, right, and bottom margins for the text. The second signature accepts a QMargins object as an argument. To build this object, you can use four integer values with the same meaning as the left, top, right, and bottom arguments in the first signature.

Here's an example of how to set custom margins for the text in a line edit:

python from PyQt6.QtWidgets import QApplication, QLineEdit class Window(QLineEdit): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Aligning Text") self.resize(300, 100) self.setText("Hello, World!") self.setTextMargins(30, 30, 0, 0) app = QApplication([]) window = Window() window.show() app.exec()

In this example, you set the left and top margins to custom values. Here's how this app looks when you run it:

QLineEdit with text margins added.

Using the setTextMargins() method, we can place the text in the desired place in a line edit, which may be a requirement in some situations.

Connecting Signals and Slots

When you're creating a GUI application and you need to use line edits, you may need to perform actions when the user enters or modifies the content of the line edit. To do this, you need to connect some of the signals of the line edit to specific slots or functions.

Depending on specific user events, the QLineEdit class can emit several different signals. Here's is a summary of these signals and their corresponding meaning:

Signal Emitted textChanged(text) Whenever the user changes the text either manually or programmatically. The text argument is the new text. textEdited(text) Whenever the user edits the text manually. The text argument is the new text. editingFinished When the user presses the Return or Enter key, or when the line edit loses focus, and its contents have changed since the last time this signal was emitted. inputRejected When the user presses a key that is an unacceptable input. returnPressed When the user presses the Return or Enter key. selectionChanged When the selection changes.

We can connect either of these signals with any slot. A slot is a method or function that performs a concrete action in your application. We can connect a signal and a slot so that the slot gets called when the signal gets emitted. Here's the required syntax to do this:

python line_edit.<signal>.connect(<method>)

In this construct, line_edit is the QLineEdit object that we need to connect with a given slot. The <signal> placeholder can be any of the abovementioned signals. Finally, <method> represents the target slot or method.

Let's write an example that puts this syntax into action. For this example, we'll connect the textEdited signal with a method that updates the text of a QLabel to match the text of our line edit:

python from PyQt6.QtWidgets import ( QApplication, QLabel, QLineEdit, QVBoxLayout, QWidget, ) class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Signal and Slot") self.resize(300, 100) self.line_edit = QLineEdit(parent=self) self.label = QLabel(parent=self) self.line_edit.textEdited.connect(self.update_label) layout = QVBoxLayout() layout.addWidget(self.line_edit) layout.addWidget(self.label) self.setLayout(layout) def update_label(self): self.label.setText(self.line_edit.text()) app = QApplication([]) window = Window() window.show() app.exec()

In this example, we connect the line edit's textEdited signal with the update_label() method, which sets the label's text to match the text we enter in our line edit. Go ahead and run the app. Then, enter some text in the line edit and see what happens with the label at the bottom of the app's window.

Validating Input in Line Edits

We can provide input validators to our line edits using the setValidator() method. This method takes a QValidator object as an argument. PyQt has a few built-in validators that you can use directly on a line edit:

Validator objects process the input to check whether it's valid. In general, validator object has three possible states:

Constant Value Description QValidator.State.Invalid 0 The input is invalid. QValidator.State.Intermediate 1 The input is a valid intermediate value. QValidator.State.Acceptable 2 The input is acceptable as a final result.

When you set a validator to a given line edit, the user may change the content to any Intermediate value during editing. However, they can't edit the text to a value that is Invalid. The line edit will emit the returnPressed and editingFinished signals only when the validator validates input as Acceptable.

Here's an example where we use a QIntValidator and a QRegularExpressionValidator

python from PyQt6.QtCore import QRegularExpression from PyQt6.QtGui import QIntValidator, QRegularExpressionValidator from PyQt6.QtWidgets import ( QApplication, QFormLayout, QLabel, QLineEdit, QWidget, ) class Window(QWidget): def __init__(self, parent=None): super().__init__(parent) self.setWindowTitle("Input Validators") self.resize(300, 100) self.int_line_edit = QLineEdit(parent=self) self.int_line_edit.setValidator(QIntValidator()) self.uppercase_line_edit = QLineEdit(parent=self) input_validator = QRegularExpressionValidator( QRegularExpression("[A-Z]+"), self.uppercase_line_edit ) self.uppercase_line_edit.setValidator(input_validator) self.uppercase_line_edit.returnPressed.connect(self.update_label) self.signal_label = QLabel(parent=self) layout = QFormLayout() layout.addRow("Integers:", self.int_line_edit) layout.addRow("Uppercase letters:", self.uppercase_line_edit) layout.addRow("Signal:", self.signal_label) self.setLayout(layout) def update_label(self): self.signal_label.setText("Return pressed!") if __name__ == "__main__": app = QApplication([]) window = Window() window.show() app.exec()

In this example, we have two line edits. In the first line edit, we've used a QIntValidator object. This way, the line edit will only accept valid integer numbers. If you try to type in something different, then the line edit won't accept your input.

In the second line edit, we've used a QRegularExpressionValidator. In this specific case, the regular expression accepts one or more uppercase letters. Again if you try to enter something else, then the line edit won't accept the input.

The QLabel will show the text Return pressed! if the input in the second line edit is valid and you press the Enter key. Here's what the app looks like:

QLineEdit with input validator.

Validators provide a quick way to restrict the user input and set our own validation rules. This way, we can ensure valid user input in our applications.


Line edits are pretty useful widgets in any GUI application. They allow text input through a single-line editor that has many cool features.

In this tutorial, you've learned how to create, use, and customize your line edits while building a GUI application with PyQt/PySide.

Categories: FLOSS Project Planets

Kay Hayen: Nuitka Release 2.0

Planet Python - Sun, 2024-02-04 18:00

This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler, “download now”.

This release had focus on new features and new optimization. There is a really large amount of compatibility with things newly added, but also massive amounts of new features, and esp. for macOS and Windows, lot of platform specified new abilities and corrections.

Bug Fixes
  • Fix, workaround for private functions as Qt slots not having names mangled. Fixed in 1.9.1 already.

  • Fix, when using Nuitka with pdm it was not detected as using pip packages. Fixed in 1.9.1 already.

  • Fix, for pydantic our lazy loader parser didn’t handle all cases properly yet. Fixed in 1.9.1 already.

  • Standalone: Added data files for pyocd package. Fixed in 1.9.1 already.

  • Standalone: Added DLL for cmsis_pack_manager package. Fixed in 1.9.1 already.

  • Standalone: Fix, the specs expanded at run time in some causes could contain random characters. Fixed in 1.9.2 already.

  • Fix, {"a":b, ...}.get("b") could crash at runtime. Fixed in 1.9.2 already.

  • Standalone: Added data files for pyproj package. Fixed in 1.9.2 already.

  • Standalone: Added more metadata requirements for transformers package. Fixed in 1.9.2 already.

  • Plugins: Fix, could crash when including packages from the command line, if they had yaml configuration that requires checking the using module, e.g. anti-bloat work. Fixed in 1.9.3 already.

  • Standalone: Added support for delphifmx package. Fixed in 1.9.4 already.

  • Android: Fix, cannot exclude libz on that platform, it’s not a full Linux OS. Fixed in 1.9.3 already.

  • Standalone: Add needed DLLs for bitsandbytes package. Fixed in 1.9.3 already.

  • Windows: Fix, newer joblib was not working anymore. Fixed in 1.9.3 already.

  • Windows: Fix, could crash when working with junctions that switch drives. Fixed in 1.9.3 already.

  • Fix, was crashing with poetry installed environments. Fixed in 1.9.3 already.

  • Standalone: Added support for newer chromadb package. Fixed in 1.9.3 already.

  • Fix, could crash in report creation on modules excluded that were asked via command line for inclusion. Fixed in 1.9.3 already.

  • Anti-Bloat: Fix for newer streamlit, it was causing SyntaxError for the compilation. Fixed in 1.9.4 already.

  • Arch: Added support for their OS release file location too. Fixed in 1.9.4 already.

  • Windows: Fix, MinGW64 doesn’t accept chinese module names a C source files. Use short paths for these instead. Fixed in 1.9.4 already.

  • Standalone: Added missing DLL for libusb_package package. Fixed in 1.9.4 already.

  • Fix, properly skip directories with non-module top level names when trying to find top level packages of distributions. Fixed in 1.9.4 already.

  • Fix, avoid memory leak bug in triggered by rich package. Fixed in 1.9.4 already.

  • Python3.11+: Fix, didn’t detect non-keywords on star dict calls in some cases. Fixed in 1.9.4 already.

  • Fix, avoid crashes due to unrecognized installers on macOS and Windows, some packages that are built via legacy fallbacks of certain pip versions do not leave any indication of their origin at all. Fixed in 1.9.4 already.

  • Windows: Fix, need to indicate that the program is long path aware or else it cannot work with the paths. Fixed in 1.9.4 already.

  • Debian: The extern namespace might not exist in the pkg_resources module, make the code work with versions that remove it and use the proper external package names then. Fixed in 1.9.6 already.

  • Compatibility: Fix, need to also have .exists method in our files reader objects. Fixed in 1.9.5 already.

  • macOS: Fix, PyQt5 standalone can fail due to libqpdf too.

  • Compatibility: Make dill-compat plugin support module mode too, previously this only worked for executables only. Fixed in 1.9.6 already.

  • Standalone: Added data file for curl_cffi package. Fixed in 1.9.6 already.

  • Windows: Fix warnings given by MinGW64 in debug mode for onefile compilation. Fixed in 1.9.6 already.

  • Python2: The handling of DLL permission changes was not robust against using unicode filenames. Fixed in 1.9.7 already.

  • Python2: Fix, could crash on Debian packages when detecting their installer. Fixed in 1.9.7 already.

  • Standalone: Added required data file for astor package. Fixed in 1.9.7 already.

  • Reports: Fix, in case of build crashes during optimization, the bug report creation could be crashing because the module is not in the list of done modules yet. Fixed in 1.9.7 already.

  • Python2: Fix, unittest.mock was not yet available, code attempting to use it was crashing the compilation. Fixed in 1.9.7 already.

  • Accelerated: Fix, tensorflow configuration removing site usage needs to apply only to standalone mode. Fixed in 1.9.7 already.

  • Plugins: Fix, the get_dist_name Nuitka package configuration function could crash in some rare configurations. Fixed in 1.9.7 already.

  • Standalone: Added necessary data file for pygame package. Added in 1.9.7 already.

  • Standalone: Fix, was not properly handling standard library overloading module names for decisions. Inclusion and compilation mode were made as if the module was part of the standard library, rather than user code. This is now properly checking if it’s also an actual standard library module.

  • Plugins: Fix, crashing on missing absence message with no UPX binary was found.

  • Windows: Fix, couldn’t load extension modules from UNC paths, so standalone distributions failed to launch from network drives. This now works again and was a regression from adding support for symlinks on Windows.

  • Standalone: Added support for non-legacy pillow in imageio package.

  • Standalone: Added required easyOCR data file.

  • Nuitka-Python: Fix, do not demote to non-LTO for “too many” modules there in the default auto mode, it doesn’t work without it.

  • Fix, python setup.py install could fail. Apparently it tries to lookup Nuitka during installation, which then could fail, due to hacks we due to make sure wheels are platform dependent. That hack is of course not really needed for install, since no collision is going to happen there.

  • macOS: Fix, the standard matplotlib plugin that uses native UI was not included yet, and it was also not working due to bindings requiring uncompiled functions, which is now worked around.

  • Compatibility: Add back PySide6 workaround for overloading names like update with slots.

  • Standalone: Added geopandas data files.

  • Python2: Fix, code objects must be made from str exactly, unicode however was used in some configurations after recent improvements to the run time path handling.

  • Standalone: Added missing data files for boto, the predecessor of boto3 as well.

  • Standalone: Added missing DLL for tensorflow factorization module.

  • Compatibility: Fix, PySide2 and PySide6 signal disconnection without arguments were not working yet.

  • Standalone: Added support for toga.

  • Scons: Fix, need to Avoid picking up clang from PATH on Windows with --clang provided, as only our winlibs version is really working.

  • Fix, version of setuptools when included (which we try to avoid very much) was None which breaks some users of it, now it’s the correct version so checks of e.g. setuptools_scm can succeed.

  • Fix, icon options for platforms were conflated, so what should be windows only icon could get used on other platforms as well.

  • Fix, could not create compiled methods from compiled methods. Also now errors out for invalid types given properly.

New Features
  • Plugins: Added support for module decisions, these are parameters provided by the user which can be used to influence the Nuitka per package configuration with a new get_parameter function. We are using these to control important choices in the user, sometimes warning it to make that decision, if the default can be considered problematic.

  • Plugins: Added support for variables in Nuitka package configurations. We can now query at compile time, values from installed packages and use them, e.g. to know what backend is to be used.

  • Standalone: Added module decision to disable Torch JIT. This is generally the right idea, but the decision is still asked for since some packages and programs want to do Torch Tracing, and that is then disabled as well. This makes a bunch of transformers programs work.

  • Standalone: Added module decision to disable Numba JIT. This makes numba work in some cases, but not all. Some packages go very deep with JIT integration, but simpler uses will now compile.

  • New option --include-onefile-external-data allows you to specify file patterns that you included by other data files others, but to put those files not inside, but on the outside of the onefile binary. This makes it easier to create deployments fully within Nuitka project configuration, and to change your mind back and forth without adding/removing the data file option.

  • macOS: Added new value auto for detecting signing identity, if only one is available in the system.

  • macOS: Added support for --copyright and --trademark information to be in app bundles as well, this was previously Windows only.

  • Windows: Added support for using junctions in the Python environment, these are used e.g. when installing via scoop. Added in 1.9.2 already.

  • Added option --cf-protection to select the control flow protection mode for the GCC compiler and deviate from default values of some environments to less strict values.

  • Reports: Added output filename to report, mainly intended for automatically locating the compilation result independent of options used.

  • Plugins: Now provides a checksum for yaml files, but not yet verifies them at runtime, to ask the user to run the checker tool to update it when they make modifications.

  • Windows: Detect when we create too large compiled executables. There is a limit of 2GB that you might e.g. violate by attempting to embed very large files. This doesn’t cover onefile yet.

  • Watch: The tool can now create PRs with the changes in Nuitka-Watch for merging, this is for using it in the CI.

  • Watch: Scanning for Python versions now requires pipenv to be installed in them to be found.

  • Watch: Added ability to create branch and PR from watch run results.

  • Plugins: Added overridden-environment-variables feature to package configuration. These are environment variable changes that only last during the import of that module and are undone later.

  • Plugins: Added force-environment-variables feature to package configuration. These are environment variable changes done on module import that are not undone.

  • Nuitka-Action: Nuitka options that can be given multiple times, cannot be specified multiple times in your workflow. As a workaround, Nuitka now allows in Actions, to use new lines as separator. This is best done with this kind of quoting a multiline string.

    include-data-dir: | a=b c=d
  • The Nuitka package configuration no-auto-follow now applies recursively, i.e. that a top level package can have it, and not every sub-package that uses a package but should not be automatically followed, does have to say this. With this e.g. networkx configuration became simpler, and yet covered automatically older versions as well, and future changes too.

  • Windows: Added support for compiling in case sensitive folders. When this option is enabled, using os.path.normcase can make filenames not found, so with a few cleanups, for lazy code that wasn’t really using the APIs designed for comparisons and filename suffix testing, this works now better.

  • The __compiled__ value has a new attribute containing_dir that allows to find where a module, accelerate executable, a standalone dist folder, a macOS app bundle, or the onefile binary lives in a consistent fashion. This allows esp. better use than sys.argv[0] which points deep into the .app bundle, and can be used cross platform.

  • Scalability: Avoid variables that are not shared to be treated as if they were, marking their type shape as tshape_unknown in the first micro pass. These micro passes are not visible, but basically constitute a full visit of the module tree over and over, until no more optimization is changing it. This can lead to quicker resolution, as that unknown type shape effectively disallowed all optimization for variables and reduce the number of necessary micro passes by one.

  • Escaped variables did provide a type shape tshape_unknown and while a lot of optimization looks for value knowledge, and gets by the escaped nature of the value, sometimes, this was seriously inhibiting some of the type based optimization.

  • Loop type shape analysis now succeeds in detecting the types for this code example, which is sort of a break-through for future performance enhancements in generated code.

    # Initial the value of "i" is "NUITKA_NINT_UNASSIGNED" in its # indicator part. The C compiler will remove that assignment # as it's only checked in the assignment coming up. i = 0 # Assignment from a constant, produces a value where both the C # and the object value are value. This is indicated by a value # of "NUITKA_NINT_BOTH_VALID". The code generation will assign # both the object member from a prepared value, and the clong # member to 0. # For the conditional check, "NUITKA_NINT_CLONG_VALID" will # always be set, and therefore function will resort to comparing # that clong member against 9 simply, that will always be very # fast. Depending on how well the C compiler can tell if an overflow # can even occur, such that an object might get created, it can even # optimize that statically. In this case it probably could, but we # do not rely on that to be fast. while i < 9: # RICH_COMPARE_LT_CBOOL_NINT_CLONG # Here, we might change the type of the object. In Python2, # this can change from ``int`` to ``long``, and our type # analysis tells us that. We can consider another thing, # not "NINT", but "NINTLONG" or so, to special case that # code. We ignore Python2 here, but multiple possible types # will be an issue, e.g. list or tuple, float or complex. # So this calls a function, that returns a value of type # "NINT" (actually it will become an in-place operation # but lets ignore that too). # That function is "BINARY_OPERATION_ADD_NINT_NINT_CLONG"(i, 1) # and it is going to check if the CLONG is valid, add the one, # and set to result to a new int. It will reset the # "NUITKA_NINT_OBJECT_VALID" flag, since the object will not be # bothered to create. i = i + 1 # Since "NUITKA_INT_OBJECT_VALID" not given, need to create the # PyObject and return it. return i
  • Python3.11+: Use tomllib from standard library for our distutils integration into pyproject based builds.

  • Avoid late specialization for None returns in generators and do it during tree building already, to remove noise.

  • Added successful detection of static libpython for self compiled Python Linux and macOS. This makes it work with pyenv as well.

  • Standalone: Avoid including .pyx files when scanning for data files, these are code files too, in this case source files that are definitely unused most of the time.

  • macOS: Make static libpython default with CPython for more compact standalone distribution and faster binaries.

  • Remove non-existent entries from sys.path, avoiding many file system lookups during import scans.

  • Anti-Bloat: Avoid using triton in torch package in more cases. Added in 1.9.2 already.

  • Anti-Bloat: Avoid using pytest in knetworkx package in more cases. Added in 1.9.2 already.

  • Anti-Bloat: Avoid using IPython in distributed package. Added in 1.9.3 already.

  • Anti-Bloat: Avoid using dask in skimage. Added in 1.9.3 already.

  • Anti-Bloat: Avoid using triton in the bitsandbytes package. Added in 1.9.3 already.

  • Anti-Bloat: Avoid IPython in tf_keras package as well. Added in 1.9.6 already.

  • Anti-Bloat: Avoid unittest in mock.mock module. Added in 1.9.7 already.

  • Avoid importing setuptools_scm during compilation when using the tqdm inline copy, this also avoids a warning on Ubuntu. Added in 1.9.7 already.

  • Anti-Bloat: Avoid doctest in skimage in their tifffile inline copy as well. Added in 1.9.7 already.

  • Anti-Bloat: Avoid h5py.tests with older h5py as well. Added in 1.9.7 already.

  • Anti-Bloat: Using distributed.utils_test is also considered using pytest.

  • Anti-Bloat: Avoid IPython in the pip package.

  • Anti-Bloat: Avoid site module for older tensorflow versions too.

  • Anti-Bloat: Avoid more unittest usages in tensorflow packages.

  • Anti-Bloat: Avoid nose in skimage package.

  • Anti-Bloat: Avoid nose in networkx package.

  • Anti-Bloat: Avoid nose in pywt package.

  • UI: Change template paths over from %VAR% to {VAR}.

    The old spec values are migrated transparently and continue to work, but get a warning when used.

    The new code detects unknown variable names and more formatting issues than before.

    Using only the {PID} value for process ID, is now making it temporary value for onefile, that was previously a bug.

    The main benefit and reason of doing this, is that Windows CMD.EXE does expand those values before Nuitka sees them as even with quoting %TEMP% is the current one on the building machine, a recipe for disaster. As some people still use that, and e.g. os.system or subprocess with shell=True will use it too, this is just not sustainable for a good user experience.

    As a result, compile time and run time variables now clash, there is e.g. {VERSION} (program version information given) and {Version} (Nuitka version), and we should clean that up too.

  • Project: Added Code of Conduct. Adapted from the one used in the Linux kernel.

  • UI: Warnings given by Nuitka used to be in red color, changed those to be yellow for consistency.

  • User Manual: Added pointer for Nuitka-Action Nuitka-Action for users interested in using Nuitka in GitHub workflows.

  • Added .gitignore to build folder that just causes these folders to be ignored by git.

  • User Manual: Added information on how to debug fork bombs from created binaries.

  • Debugging: The output of --experimental=--report-refcounts that we use to show leaks of compiled time objects at program exit, now counts and reports on functions, generator objects and compiled cells as well.

  • Quality: Warnings from yamllint not disabled are errors. These were only output, but didn’t cause the autoformat to error exit yet.

  • UI: Enhanced formatting of info traces, drop the :INFO part that shouts, and reserve that for errors and warnings. Also format info messages to make sure they fit into the line.

  • UI: Changed --show-source-changes to accept module pattern to make it easier to only see the ones currently being worked on. To get the old behavior of showing everything, use * as a pattern.

  • UI: Allow using ~ in data files source path for command line options and expand it properly.

  • Quality: Enhanced schema for our package configuration yaml files to detect suffixes with leading dots, that is not wanted. These now fail checks, but we also tolerate them now.

  • Quality: Check module names used in the package configuration yaml files for validity, this catches e.g. trailing dots.

  • Quality: Make sure to really prefer clang-format from Visual Code and MSVC for formatting C code, otherwise a system installed one could be used that gives slightly different outputs.

  • Scons: Allow disabling to enforce no warnings for C compilation

    Currently only for gcc, where we need it until loop tracing is better, we can now use --experimental=allow-c-warnings options to make --debug work for some known currently unavoidable warnings.

  • macOS: Make --macos-create-app-bundle imply standalone mode, it’s not working or useful for accelerated mode anyway.

  • Standalone: Added support for using self-compiled Python versions that are not installed on Linux and macOS. This avoids having to do make install and can ease debugging with changes made in Python core itself. Added in 1.9.6 already.

  • Release: Added ability to simple re-date hotfixes. Previously the version bump commit needed to be dropped, now a fixup commit is easy to generate.

  • Release: Man pages are no longer built during package builds, but are available statically in the git, which should make it easier.

  • Release: Disable verbose output in package installation of Nuitka, it never was any use, and just makes things hard to read.

  • UI: Check user yaml file present immediately. Otherwise it was crashing when parsing yaml files first time with less comprehensible exceptions. Added in 1.9.7 already.

  • Quality: Updated to latest rstfmt, black and isort versions.

  • Debian: Remove references to PDF documentation that no longer exists.

  • Quality: Do not crash when collecting modified files due to deleted files.

  • UI: Detect the Alpine flavor of Python as well.

  • UI: Detect manylinux Pythons as a Python flavors as well.

  • UI: Detect self compiled uninstalled Python as a dedicated flavor.

  • For the Nuitka-Action part of the available options is now generated from Nuitka option definitions itself, adding some previously missing options as a result. As a result, adding --include-onefile-external-data was automatic this time.

  • The warnings for onefile only options without onefile mode provided have been moved to common code, and in some cases were having wrong texts corrected.

  • Use enum definitions in the Nuitka package configuration schema rather than manual oneOf types.

  • The User Manual was proof read and had a bunch of wordings improved.

  • Cleanup, avoid “unused but set variable” warning from the C compiler for hard some forms of hard imports.

  • Prefer os.getenv over os.environ.get for readability.

  • Changed parts of the C codes that clang-format had a hard time with to something more normal.

  • When locating the standalone binary created, use a compilation report and resolve the path specified there. This allows macOS app bundles to be used in these tests as well.

  • Made the PyQt tests executable on macOS too adding necessary options.

  • Added reference test case for unpacking into a list, this was not covered but under suspect of reference leaking which turns out to be wrong.

  • Much enhanced usage of virtualenv in the distutils test cases. We make more sure to delete them even in case of issues. We disable warnings during Nuitka package installation. The code to execute a case was factored out and became more clear. We now handle errors in execution with stating what case actually failed, this was a bit hard to tell previously. Also do not install Nuitka when a pyproject case is used, since the build tool installs Nuitka itself.


This release deserves the 2.0 marker, as it is ground breaking in many ways. The loop type analysis stands out on the optimization front. This will open an avenue for much optimized code at least for some benchmark examples this summer.

The new features for package configuration, demonstrate abilities to avoid plugins for Nuitka, where those previously would have been used. The new variables and parameters made it unnecessary to have them, and still add compile time variable use and user decisions and information, without them.

The scope of supported Python configurations got expanded a bit, and the the usual slew of anti-bloat work and new packages supported, makes Nuitka an ever more round package.

The improved user dialog with less noisy messages and slightly better coloring, continues a trend, where Nuitka becomes more and more easy to use.

Categories: FLOSS Project Planets

TechBeamers Python: How to Find the List Shape in Python

Planet Python - Sun, 2024-02-04 14:25

Welcome to this short tutorial where we’ll explore how to get the list shape in Python. This knowledge becomes essential when working with multi-dimensional data structures, like lists of lists a.k.a. nested lists or NumPy arrays. Let’s dive into the methods available to achieve this in Python with some good examples. What Does a List […]

The post How to Find the List Shape in Python appeared first on TechBeamers.

Categories: FLOSS Project Planets

TechBeamers Python: Pandas Get Average Of Column Or Mean in Python

Planet Python - Sun, 2024-02-04 13:00

Welcome to another Python tutorial on Pandas! In this guide, we’ll explore how to get the average of a column using the powerful Pandas library. Pandas is a versatile data manipulation and analysis library that provides easy-to-use data structures for handling and analyzing structured data. If you’re working with datasets in Python, Pandas is a […]

The post Pandas Get Average Of Column Or Mean in Python appeared first on TechBeamers.

Categories: FLOSS Project Planets

TechBeamers Python: Sorting List of Lists in Python Explained With Examples

Planet Python - Sun, 2024-02-04 06:32

Sorting lists of lists in Python presents a challenge when you need to organize structured data with multiple levels. Python’s built-in sorting methods don’t directly handle this complexity. To achieve the desired sorting, you need to leverage specific techniques. We’ll be detailing the solution and provide ready-to-use methods that you can directly consume in your […]

The post Sorting List of Lists in Python Explained With Examples appeared first on TechBeamers.

Categories: FLOSS Project Planets

libredwg @ Savannah: libredwg-0.13 released

GNU Planet! - Sun, 2024-02-04 04:53

Can now also read and write all DWG formats pre-R13.
See https://www.gnu.org/software/libredwg/ and https://github.com/LibreDWG/libredwg/blob/0.13/NEWS
Now we'll finish work on encode support for r2004+.

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.gz (17.4MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.xz (9MB)

Here are the GPG detached signatures[*]:

Use a mirror for higher download bandwidth:

Here are more binaries:

Here are the SHA256 checksums:

9682b0c5e6d91720666118059c67bf614e407a49b1a3c13312fe6a6c8f41d9cf  libredwg-0.13.tar.gz
dd906f59d71b26c13fd2420f50fc50bea666fd54acc764d8c344f7f89d5ab94e  libredwg-0.13.tar.xz
cc5df6456cdc7d0c9ebcd2eb798b81a80aab6b3a8f5417d4598262f3d2120886  libredwg-0.13-win32.zip
34774d2cd1c87f00a1d647f6c172ff92d02bab4ebe586badd883772fb746218b  libredwg-0.13-win64.zip

[*] Use a .sig file to verify that the coresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.13.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

Categories: FLOSS Project Planets

TechBeamers Python: Pandas Add Row Using Multiple Methods

Planet Python - Sun, 2024-02-04 02:49

This tutorial provides a thorough overview of different methods you can use to add a row in Pandas. While using Pandas with Python, we may need to update existing data and add rows in real-time. Hence, it is vital to understand these methods for effective data analysis. Pandas – How to Add a Row in […]

The post Pandas Add Row Using Multiple Methods appeared first on TechBeamers.

Categories: FLOSS Project Planets

Fabio Zadrozny: PyDev Debugger and sys.monitoring (PEP 669) -- i.e.: really fast debugging for Python 3.12!

Planet Python - Sat, 2024-02-03 21:51

The latest release of PyDev (12.0.0) is now available and it brings a really nice speed improvement for those who are already in Python 3.12! -- If you're a LiClipse user, it's now available in LiClipse 11.

The PyDev Debugger now uses sys.monitoring, which enables faster debugging (on my tests it can be up to 15 times faster than the version using sys.setttrace, depending on the use case -- kudos to Mark Shannon for PEP 669 😉).

It took me a while to cover the many scenarios that pydevd deals with, but the good thing is that most of the infrastructure available in pydevd didn't need changes (the debugger already had all the concepts needed as it already tried to trace only the frames which were actually needed, which definitely helped a lot as this is now pretty central in how to deal with the tracing using sys.monitoring)

Given that it's now out, I'll talk about how it works and some of the caveats when using it.

So, the first thing to note is that PEP 669 defines a bunch of callbacks which are now related to the code object (and not the frame as happened with sys.settrace) and when inside one of those callbacks the debugger can react to decide what should happen.

Some things that could happen could be pausing due to a breakpoint or a step instruction or deciding that the given code should not be traced again (by returning a DISABLE).

The reason it becomes faster than the previous approach is that the DISABLE is then considered by the Python interpreter which then bakes that DISABLE into the code when it's executing (up until sys.monitoring.restart_events() is called again). This does come with a big caveat though: if there are multiple threads running the program and one of those threads returns a DISABLE instruction then the related callback will actually be disabled for all the threads. Note that if DISABLE is not returned, the speed ends up being close to what was available with sys.settrace (which wasn't all that bad in pydevd already, but definitely a step down from what is now available).

This means that the debugger is really much faster when going for a breakpoint (because it can DISABLE many of the tracing instructions), but after a breakpoint is hit, if one thread is doing a step operation, then the speed reverts back to being close to the sys.settrace variant (the debugger can still DISABLE tracing for places it knows the user never wants to stop, but it cannot DISABLE the tracing for any code in any thread where the user may want to stop, because the thread which is stepping could be affected by a DISABLE in another thread which is not stepping, or at least the stepping must be considered for all threads even if a given thread hasn't really stopped and is not stepping).

Also, it's worth to mention that sys.monitoring has finer grained events vs. the ones available in sys.settrace, which is good as for instance, it's possible to get events from exceptions separate from events related to entering/returning from a function or lines, which helps the debugger in tracing only what's actually needed (the tracing debugger had to do lots of gymnastics to create a separate tracer just for exceptions when there would be no need to trace a given scope for lines, so, the new code ends up being both simpler and faster).

Note however that in pydevd I've done some other improvements and stepping should be more responsive even when using sys.settrace with older versions of Python!

p.s.: the attach to process is still not available for Python 3.12

Note: back in the day other players which make use of pydevd such as JetBrains and Microsoft did step up to finance it, but at this point the only support it has is from backers in the community.

So, if you enjoy using pydevd please consider becoming a supporter... I've actually just setup sponsoring through GitHub sponsorships (https://github.com/sponsors/fabioz). Any takes on becoming one of the first backers there 😉?

Categories: FLOSS Project Planets

Kubuntu Council Meeting – 30th January 2024

Planet KDE - Sat, 2024-02-03 20:28

Greetings, Kubuntu Community!

Today marked an important Kubuntu Council meeting, where we witnessed significant progress and collaboration among our esteemed council members – Darin Miller, Rik Mills, Valorie Zimmerman, Aaron Honeycutt, Jonathan Riddell (Kubuntu Treasurer), and Simon Quigley(Lubuntu). In this blog post, we’re excited to share the highlights and outcomes of the discussions that took place.

  1. Focus on the Upcoming Kubuntu LTS Release 24.04

    A primary focus of our meeting was setting the objectives for the imminent Kubuntu LTS release. The council engaged in in-depth discussions to ensure that the upcoming release meets the high expectations of our community and continues the Kubuntu legacy of excellence.
  2. Ubuntu Flavours Statement of LTS Support

    Understanding the importance of clear communication, we considered the necessity of a statement regarding Long-Term Support (LTS) required by Ubuntu recognised flavours. This move aligns with our commitment to provide transparency and detailed information to our users.
  3. Exciting Collaboration with Scarlett Gately Moore

    We’re thrilled to announce that we have agreed to contract Scarlett Gately Moore for a three-month period. With a preliminary budget allocated, Scarlett will play a crucial role in delivering key projects:-

    – The 24.04 LTS Release,
    – Updating the Kubuntu Installer to Calamares,
    – Preparing an Alpha of Plasma 6 targeting the 24.10 release.

    This decision was unanimously agreed upon and reflects our dedication to continually enhancing Kubuntu.
Actions Moving Forward:

Coordination and Oversight: Simon Quigley will be coordinating with Rik Mills and Scarlett Moore, managing the intricate details and ensuring the smooth delivery of our objectives.

Financial Processes: Simon Quigley will oversee the invoicing process with Scarlett Moore, following the agreed pro-forma. Jonathan Riddell, our Kubuntu Treasurer, will handle the commissioning of payments.

Communication and Documentation: As a part of our commitment to keep the community informed, I, Rick Timmis, will be updating the Kubuntu Council mailing list about the meeting’s outcomes. Additionally, I will draft an LTS Statement for submission to the Ubuntu Technical Board, detailing our approach and commitment to Kubuntu’s Long-Term Support.

This meeting was a testament to the dedication and passion of our council members and the broader Kubuntu community. We’re excited about the direction in which Kubuntu is heading and are eager to see the fruition of these projects.

Stay tuned for more updates, and thank you for your continued support of Kubuntu!


Best Regards,

Rick Timmis
Kubuntu Council

Categories: FLOSS Project Planets

Armin Ronacher: Rye: A Vision Continued

Planet Python - Sat, 2024-02-03 19:00

In April of last year I released Rye to the public. Rye, both then and now, represents my very personal vision of what an improved Python packaging and project management solution can look like. Essentially, it's a comprehensive user experience, designed so that the only tool a Python programmer would need to interface with is Rye itself and it gets you from zero to one in a minute. It is capable of bootstrapping Python by automatically downloading different Python versions, it creates virtualenvs, it manages dependencies, and lints and formats. Initially developed for my own use, I decided to release it to the public, and the feedback has been overwhelmingly positive.

When I introduced it, I initiated a discussion thread titled “Should Rye Exist” referencing the well known XKCD #929 which humorously comments on the proliferation of competing standards. I did not feel well throwing yet another Python packaging tool into the ring.

Yet it exists now and has user. This standard issue however I think is helped a bit by the fact that Rye doesn't actually do any of these things itself. It wraps established tools:

  • Downloading Python: it provides an automated way to get access to the amazing Indygreg Python Builds as well as the PyPy binary distributions.
  • Linting and Formatting: it bundles ruff and makes it available with rye lint and rye fmt.
  • Managing Virtualenvs: it uses the well established virtualenv library under the hood.
  • Building Wheels: it delegates that work largely to build.
  • Publishing: its publish command uses twine to accomplish this task.
  • Locking and Dependency Installation: is today implemented by using unearth and pip-tools.

As you can see, Rye is not revolutionary and it's not intended to be. Rye itself doesn't do all that much as it delegates all the core functionality to other tools in the ecosystem. Rye packages these tools together in a user-friendly manner, significantly reducing the cognitive load for developers. This convenience eliminates the need to learn about various tools, read extensive documentation, and integrate these components independently. Rye lets you get from no Python on a computer to a fully functioning Python project in under a minute with linting, formatting and everything in place. It is sufficiently opinionated that many important decisions are made for you. For instance it starts you out with using pyproject.toml and picks a wheel build system for you. It also picks the linter and formatter, and the preferred Python distribution and decides on a build tool.

Defaults Matter

Rye is designed to select the best tools for the job — it picks winners. Why does it do that? This approach is inspired by my admiration for the developer experience in the Rust ecosystem, particularly the seamless integration of rustup and cargo. Their functionality made me long for a similar experience within the Python community. Crucially the way this works in the Rust world does not mean that cargo does everything. When you run cargo build it invokes rustc, when you run cargo doc it runs rustdoc. When you invoke cargo clippy it runs clippy for you and so worth. Cargo is a manager that delegates the important work to bespoke tools that are improved by sometimes entirely different teams. This also means that tools can be swapped out if they are found to be not the right choice any more. The experience in the Rust world also showed me that excellent Windows support is just a must have. That's why Rye is not just a great experience on macOS and Linux, it's also excellent on Windows.

I am convinced that the Python community is deserving of an excellent developer experience, and Rye, as it stands today, offers a promising beginning. My belief is supported by evidence gathered from conducting in-person user interviews and demos, where Rye was well received. In fact, every individual who I was able to give a guided tour of Rye was impressed by how swiftly one could start working with Python. Because it was demonstrably designed to avoid interference with any pre-existing Python configurations, Rye allows for a smooth and gradual integration and the emotional barrier of picking it up even for people who use other tools was shown to be low.

That said, Rye is a one person project and it does not address the fundamental challenges of some of the issues we have in the Python ecosystem. It does not solve multi version dependencies, it does not offer better performance for the installation of dependencies. It does not help with distributing executables for end user applications or anything like this. However I am getting multiple signals that the time is right for a tool like Rye to not just exist, but also to rally a larger number of the Python community embrace some of these standardization ideas.

What's Next?

Chris Warrick recently wrote a blog post where he looked back at the last year of Python packaging that made the rounds on Twitter. It laments a bit that we did not make much of a progress in packaging and it also talks a bit about Rye and correctly points out that Rye does not have enough contributors (basically just me). That's not a healthy setup.

I still don't really know if Rye should exist. It has not yet become established and there are plenty of rough edges. I personally really enjoy using it but at the same time every time I use it, I get reminded that it would stop existing if I did not invest time into it which in some sense is what keeps me going on it.

However I would love to see the community converge to a Rye like solution, no matter where it comes from.

Learn More

Did I spark your interest? I would really appreciate it if you give it a try and give feedback:

a 16 minute introduction to Rye

Categories: FLOSS Project Planets

gnuastro @ Savannah: Gnuastro 0.22 released

GNU Planet! - Sat, 2024-02-03 18:19

The 22st release of GNU Astronomy Utilities (Gnuastro) is now available. See the full announcement for all the new features in this release and the many bugs that have been found and fixed: https://lists.gnu.org/archive/html/info-gnuastro/2024-02/msg00000.html

Categories: FLOSS Project Planets

TechBeamers Python: Python Pandas Tutorial to Learn Series and DataFrames

Planet Python - Sat, 2024-02-03 13:22

Python Pandas library is a perfect tool for deep analysis and modification of large data. It provides two basic data structures which are Series and DataFrame with several functions to create, clean, and index the data. Since Pandas embeds all such features, it naturally becomes invaluable for complex statistical tasks ranging from basic data cleaning […]

The post Python Pandas Tutorial to Learn Series and DataFrames appeared first on TechBeamers.

Categories: FLOSS Project Planets

TechBeamers Python: How to Fetch the List of Popular GitHub Repos

Planet Python - Sat, 2024-02-03 04:23

Introduction In this guide, we’ll walk you through a straightforward Python script that taps into the GitHub API to fetch the list of popular repositories. We’ll be using the requests module, a handy tool for making HTTP requests in Python. Why Need Popular GitHub Repositories? Popular GitHub repositories help developers stay updated on community trends. […]

The post How to Fetch the List of Popular GitHub Repos appeared first on TechBeamers.

Categories: FLOSS Project Planets

Talk Python to Me: #447: Parallel Python Apps with Sub Interpreters

Planet Python - Sat, 2024-02-03 03:00
It's an exciting time for the capabilities of Python. We have the Faster CPython initiative going strong, the recent async work, the adoption of typing and on this episode we discuss a new isolation and parallelization capability coming to Python through sub-interpreters. We have Eric Snow who spearheaded the work to get them added to Python 3.12 and is working on the Python API for 3.13 along with Anthony Shaw who has been pushing the boundaries of what you can already do with subinterpreters.<br/> <br/> <strong>Episode sponsors</strong><br/> <br/> <a href='https://talkpython.fm/pdm2024-v3'>Pybites PDM</a><br> <a href='https://talkpython.fm/sentry-monorepo'>Sentry Error Monitoring, Code TALKPYTHON</a><br> <a href='https://talkpython.fm/training'>Talk Python Courses</a><br/> <br/> <strong>Links from the show</strong><br/> <br/> <div><b>Guests</b><br/> <b>Anthony Shaw</b>: <a href="https://fosstodon.org/@tonybaloney" target="_blank" rel="noopener">@tonybaloney@fosstodon.org</a><br/> <b>Eric Snow</b>: <a href="https://mastodon.social/@ericsnowcurrently" target="_blank" rel="noopener">/@ericsnowcurrently@mastodon.social</a><br/> <br/> <b>PEP 684 – A Per-Interpreter GIL</b>: <a href="https://peps.python.org/pep-684/" target="_blank" rel="noopener">peps.python.org</a><br/> <b>PEP 734 – Multiple Interpreters in the Stdlib</b>: <a href="https://peps.python.org/pep-0734/" target="_blank" rel="noopener">peps.python.org</a><br/> <b>Running Python Parallel Applications with Sub Interpreters</b>: <a href="https://fosstodon.org/@tonybaloney/111427911923421383" target="_blank" rel="noopener">fosstodon.org</a><br/> <b>pytest subinterpreters</b>: <a href="https://fosstodon.org/@tonybaloney/111469609963107109" target="_blank" rel="noopener">fosstodon.org</a><br/> <b>Long-Term Vision for a Parallel Python Programming Model?</b>: <a href="https://fosstodon.org/@tonybaloney/111462833872583023" target="_blank" rel="noopener">fosstodon.org</a><br/> <br/> <br/> <b>Hypercorn Server</b>: <a href="https://github.com/pgjones/hypercorn/" target="_blank" rel="noopener">github.com</a><br/> <b>msgspec</b>: <a href="https://jcristharif.com/msgspec/benchmarks.html" target="_blank" rel="noopener">jcristharif.com</a><br/> <b>Dill package</b>: <a href="https://pypi.org/project/dill/" target="_blank" rel="noopener">pypi.org</a><br/> <b>Watch this episode on YouTube</b>: <a href="https://www.youtube.com/watch?v=gW1sBMfRPjg" target="_blank" rel="noopener">youtube.com</a><br/> <b>Episode transcripts</b>: <a href="https://talkpython.fm/episodes/transcript/447/parallel-python-apps-with-sub-interpreters" target="_blank" rel="noopener">talkpython.fm</a><br/> <br/> <b>--- Stay in touch with us ---</b><br/> <b>Subscribe to us on YouTube</b>: <a href="https://talkpython.fm/youtube" target="_blank" rel="noopener">youtube.com</a><br/> <b>Follow Talk Python on Mastodon</b>: <a href="https://fosstodon.org/web/@talkpython" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>talkpython</a><br/> <b>Follow Michael on Mastodon</b>: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" rel="noopener"><i class="fa-brands fa-mastodon"></i>mkennedy</a><br/></div>
Categories: FLOSS Project Planets

This week in KDE: converging on a release

Planet KDE - Sat, 2024-02-03 01:08

Believe it or not, the mega-release is coming out in less than a month. So soon! For this reason, all hands are on deck fixing bugs and polishing everything up. Nonetheless, the next releases of Plasma and KDE apps are starting to accumulate some juicy improvements too! Read on to find out…

KDE 6 Mega-Release

(Includes all software to be released on the February 28th mega-release: Plasma 6, Frameworks 6, and apps from Gear 24.02)

UI improvements

When you drag a file in the Plasma Wayland session and it passes over another window during the journey to its final destination, the window it passes over only raises itself to the top when you stop moving the cursor for a full second–up from the previous value of one quarter of a second (Xaver Hugl, link)

Panels in “Auto-Hide” (or the new “Dodge Windows”) mode that are currently hidden no longer inappropriately show themselves when the system wakes from sleep or its screen configuration changes (Vlad Zahorodnii, link 1 and link 2)

Made some more improvements to the ranking of KRunner search results (Alexander Lohnau, link)

The gray groove in scrollbar tracks that shows up on hover has been removed, because it didn’t really add anything since the whole scrollbar area is already framed. In the future if and when we remove that frame, the groove may re-appear, though (Akseli Lahtinen, link 1 and link 2):

When using the Breeze Dark Plasma style or color scheme, Plasma widget popups no longer have a white-ish flash while opening (Niccolò Venerandi, link)

The Clipboard and Keyboard Indicator System Tray applets now hide themselves completely when they have nothing to show, instead of appearing in the expanded part of the system tray and just showing you some kind of generic “there’s nothing to see here, hurr hurr” message when clicked (Jin Liu, link 1 and link 2)

Made the colors and line weights of single-pixel separators and outlines throughout Breeze-themes KDE software consistent, as many were previously using subtly different colors and line weights (Akseli Lahtinen and Marco Martin, link 1, link 2, link 3, link 4, link 5)

Bug fixes

Important note: I don’t mention fixes for bugs that were never released to users; it’s just too much for me (it would probably be too much for you to read as well), and most people never encountered them in the first place. Because we’re in the middle of a big Plasma dev cycle, there are a lot of these bugs! So big thanks to everyone who’s made it a priority to fix them!

It’s no longer possible to crash Plasma by giving a virtual desktop an absurdly long name (Vlad Zahorodnii, link)

It’s now possible to use Alt+PrintScreen as a key combination for global shortcuts (Yifan Zhu, link)

System Monitor’s “Import Page” functionality once again works (Arjen Hiemstra, link)

Plasma tooltips now get their visual styling from the active Plasma style’s Tooltip SVG, instead of its Dialog SVG, which was kinda weird (David Edmundson, link)

Made a bunch of fixes and improvements for windows using fractional scale factors (Akseli Lahtinen and Kai Uwe Broulik, link 1, link 2, link 3, and link 4)

With the Breeze application style, those rare menu items with multiple lines of text are now displayed correctly (Ilya Bizayev, link)

The kinfo command-line program now correctly reports your graphics platform (i.e. X11 or Wayland) (Harald Sitter, link)

Other bug information of note:

Performance & Technical

Fixed a bug affecting with certain GPU setups that could cause KWin to use 100% of a CPU core whenever anything was using PipeWire to record the screen–which is actually quite a lot of things, including window thumbnails in the Task Manager and Overview effect (Xaver Hugl, link)

the Kickoff Application Launcher is now hugely more performant and faster to switch categories when hovering the cursor over multiple list items quickly (David Edmundson and Nicolas Fella, link 1 and link 2)

Made multiple improvements to reduce the amount of blocking when browsing mounted network file systems (Sergey Katunin, link 1 and link 2)

The “Closeable” window rule now works in the Plasma Wayland session (Vlad Zahorodnii, link)


Spectacle’s text tool now lets you insert line breaks and wrap text (Noah Davis, Spectacle 23.05. Link)

KCalc now uses a more modern frameless style (Carl Schwan, KCalc 24.05. Link):

The Weather widget now displays the chance of precipitation for all data providers except for BBC, which doesn’t provide this information (I guess it’s easier to just assume the chance is 100% for any location in the UK) (Ismael Asensio, Plasma 6.1. Link 1 and link 2):

When you have more then one audio input or output device, the name of each one shown in the System Tray widget is now a lot more readable and comprehensible, and doesn’t include weird technical text that often made no sense (Harald Sitter, Plasma 6.1. Link):

Notifications showing file transfer or download jobs now have a clearer arrangement of buttons (Oliver Beard, Plasma 6.1. Link):

When you activate the logout screen by invoking a specific action (e.g. “Shut Down”), it will now act more like a confirmation screen and only show you that action plus a cancel button (me: Nate Graham, Plasma 6.1. Link):

Right-clicking on a panel now yields a menu item that says “Show Panel Configuration”, which is clearer than the old “Enter Edit Mode” (Marco Martin, link)

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

Thanks to you, our Plasma 6 fundraiser has been a crazy success! I originally thought the goal of 500 new KDE e.V. supporting members was over-optimistic, but you’ve all proven me happily wrong. We’re now up to an incredible 695 members, unlocked both stretch goals, and 1000 members by launch time seems like it might even be feasible. Thank you everyone for the confidence you’ve shown in us; we’ll try not to screw it up! For those who haven’t donated ot become members yet, spreading the wealth via this fundraiser is a great way to share the love.

If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Which issues? These issues. Plasma 6 is very usable for daily driving now, but still in need of some final bug-fixing and polishing to get it into a solid state by February.

Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Categories: FLOSS Project Planets

Junichi Uekawa: February already.

Planet Debian - Fri, 2024-02-02 16:42
February already. I was planning on doing some Debian Rust stuff but then I need to reconstruct my environment.

Categories: FLOSS Project Planets

Nonprofit Drupal posts: FREE DrupalCon Portland Ticket! Volunteer to lead a breakout session at the Nonprofit Summit.

Planet Drupal - Fri, 2024-02-02 15:31

We have confirmed with the Drupal Association that Nonprofit Summit breakout leaders will receive FREE admission to the conference. So submit your ideas today!

You don’t have to be a developer to lead a discussion! We still need topic ideas that include the experiences of Drupal site builders and Drupal users, content editors, and decision-makers, in addition to technical topics.

(Side note to CiviCRM fans: we've heard you loud and clear. This topic is thoroughly represented.)

Original Message

Hey nonprofit Drupal users! The DA is interested in supporting community-driven content that is specifically relevant to nonprofit organization staff and related agencies at DrupalCon North America in Portland, Oregon, at the Nonprofit Summit on May 9, 2024.

We are looking for volunteers who would be interested in giving back to the community by contributing some subject matter expertise via a day of informal breakout sessions or other group activities. We are open to ideas!

Who are we looking for?

Do you have some Drupal expertise or a recent experience with a Drupal project that you would like to share with others? Is there something about Drupal that you think is really cool that you would love to share with the nonprofit Drupal community?

What’s required?

You will not be required to make slides! You don’t need to have lots of (or any) speaking experience! All you need is a willingness to facilitate a discussion group or engaging activity around a particular topic, and some expertise or enthusiasm for that topic that you wish to share. 

How to Submit an Idea or Topic

Please fill out this form by February 13th and we will get back to you as soon as we are able. Thank you! https://forms.gle/MJthh68rsFeZsuVc8

Discussion leaders will be selected by the Nonprofit Summit Planning Committee and will be notified by the end of February


Email nonprofitsummit@association.drupal.org.

Categories: FLOSS Project Planets