FLOSS Project Planets

KDE's July 2020 Apps Update

Planet KDE - Thu, 2020-07-09 08:00
New releases KTorrent 5.2.0

File sharing app KTorrent had a new release 5.2.0.

The import improvement for sharing is Distributed Hash Table improvements which now bootstraps with well-known nodes so you can get your downloads faster. Under the hood it updates to the newer QtWebengine which is based on Chrome away from the older QtWebkit based on WebKit (all of them are based on KDE’s KHTML back in the day).


KTorrent is available in your Linux distro.

KMyMoney 5.1.0 released

Banking app KMyMoney released 5.1.

It adds support for the Indian Rupee symbol: ₹. They also added the option to “Reverse charges and payments” to OFX import and the budget view now displays all account types.


KMyMoney is available in your Linux distro, as a Windows download, a Mac download and now in Homebrew KDE.

KDiff3 1.8.3 Release Notes

File comparison tool KDiff3 released a new version 1.8.3 was released with a bunch of stability fixes.

Using KDiff3 as a difftool for Git will no longer trigger errors on non-existent files. Errors during directory comparison are properly queued so only one message will appear. Fixes reload on Windows. Removed a crash when clipboard is not available. Full screen toggle has been reworked to avoid a problematic Qt API call.

You can download KDiff3 for Windows, Mac and your Linux distro.

App Store Microsoft Store Stats

Christoph Cullmann gave us an update on the Microsoft store. Kate and Okular have been updated and in the last month have both had over 4000 installs.

Kate App Store Interview: Flathub

Flatpak is one of the new container based formats changing how we get our apps on Linux. Flatpak can work with any host who wants to set up a store but the definitive store is Flathub.

Recently Flathub helper Timothée Ravier asked for help putting more KDE apps in the store. We interviewed him to find out more.

Tell us about yourself, where are you from, what do you do for a living, how did you get into open source and Flatpaks?

My name is Timothée Ravier and I am currently living in Paris, France. I am a Linux system engineer and I currently work at Red Hat on Red Hat CoreOS and Fedora CoreOS.

I got into open source when I first installed a Linux distribution in 2006 and never stopped since. Most of the research projects I undertook during my studies were related to the security of Linux, application sandboxing and graphical interface security. Thus the Flatpak introduction and development piqued my interest.

In my spare time I maintain the unofficial KDE variant (nicknamed Kinoite) of Fedora Silverblue. In short, Fedora Silverblue is an immutable operating system and the recommended way to install applications is to use Flatpaks or containers (via podman). See the documentation for more details.

What made you put out your recent call for KDE apps in Flathub?

First I want to say a big “Thank you” to the current maintainers that already maintain KDE Apps on Flathub as they are doing a great job!

I have been a long time KDE user (I started in 2006) and I always wanted to contribute back. Distributions already have teams of established maintainers and Flathub was missing a good bunch of KDE Apps so it felt like a good place to start.

I also made a call as it will be easier if we split the work and maybe that will also make more people aware of Flatpaks and Flathub.

Flatpak can work from any repository, why the need for Flathub?

This question highlights one of the advantages of Flathub: you can host your own repository of applications on your own server and distribute them directly to your users. You do not “need” Flathub.

But just like you do not need GitHub or GitLab, etc. to host a Git repository, it is much easier to collaborate if you have a single place to point users and developers at.

Flathub has become the easiest place to find and safely try Linux applications, both open source and proprietary. I think this is critical if we want to improve the attractiveness of the Linux ecosystem as a desktop platform.

What other open source communities have embraced putting their apps on Flathub?

I think that a lot (maybe most) of the GNOME applications are now available on FlatHub.

Now that the app developers can put out our software directly on stores like Flathub there are new responsibilities like security and keeping software up to date. Can you say how well these are handled into Flathub?

With Flathub, the responsibilities are shared between the Platform maintainers and the application maintainers.

The Platforms contain the core library common to a lot of applications (there are Freedesktop, GNOME and KDE platforms) and are maintained to preserve both ABI compatibility and ensure prompt security updates.

Updates to the remaining libraries required by an application and the application itself are the responsibility of the application maintainer.

Which KDE apps do you find most useful?

I use Dolphin, Konsole, Yakuake, Okular and Ark daily and I really like them. I also appreciate and use Gwenview, KCachegrind and Massif-Visualizer from time to time.

Many of our apps are packaged as Flatpaks through our invent and binary-factory servers are you working with these processes or separately?

The Flatpaks that are built on the KDE infrastructure are intended to be nightly builds for developers and users to try out. This is a good pool of Flatpak applications to get started but some of them also need to be updated. Keeping this repository updated will help us with recent developments that may require packaging changes on Flathub. I have not yet started updating them but I will try to do it along the applications submission to Flathub.

Can you see a time when RPMs and Apt are no more and Linux distros all use container packages?

I don’t think this will ever happen as there is value in how distributions currently package apps even though it also has issues. But I think that less distribution will put in the effort to do it. For example, Fedora builds Flatpaks from RPM packages and makes them available for everyone. You could also potentially do the same with Debian packages. The value here isn’t in the what but the who: do you trust this distribution? Its values? Its commitment to free software only? Then you are sure that the applications that you install from their repo will have the same requirements that every other package. Flathub has both open source and proprietary apps and that may not be for everybody.

Releases Now on kde.org/applications

Our Applications sub-site has started showing release info on it. Expect more to come soon. If you are an app maintainer remember to add the release info to the Appstream files.

Release Info Releases 20.04.3

Some of our projects release on their own timescale and some get released en-masse. The 20.04.3 bundle of projects was released today and will be available through app stores and distros soon. See the 20.04.3 releases page for details.

Some of the fixes in today’s releases:

  • Previews of desktop files in Dolphin have been fixed for absolute icon paths
  • Completed To-Do items are now correctly recorded in KOrganizer’s journal
  • Multi-line text pasted from GTK applications into Konsole no longer has extra “new line” characters
  • Yakuake’s maximization behavior has been fixed

20.04 release notesPackage download wiki page20.04.3 source info page20.04.3 full changelog

Categories: FLOSS Project Planets

Drupal In the News: Drupal Association Launches Drupal Steward Program To Increase Protection For Site Owners

Planet Drupal - Thu, 2020-07-09 07:20

The Drupal Steward Program enhances the security of Drupal Sites by protecting sites from exploits even before they are able to patch, and supports the sustainability of the Drupal Security Team and Drupal Association.

PORTLAND, Ore. July 7, 2020—The Drupal Association is announcing the launch of the Drupal Steward security program, together with founding partners Acquia and Pantheon, two of the largest hosting platforms for Drupal, and major contributors to the project. This is a paid service offered to further enhance the sites built on Drupal. A portion of the proceeds from both the founding partners and the community tier are used to support the Drupal Security Team and Drupal Association.

The Drupal Steward program answers the most pressing concern that keeps CIOs/CTOs up at night - "How do I protect my sites from the next unknown vulnerability?" In today's world, a Public Service Announcement of a critical vulnerability means disruption to existing engineering roadmaps, overtime hours, and all-hands on deck waiting for a patch release so that it can be deployed before bad actors reverse engineer the vulnerability.

Drupal Steward addresses this issue by putting in place a network-level mitigation strategy that prevents many of these kinds of highly critical vulnerabilities from being exploited, even before the patch has been applied. While there may be some rare vulnerabilities that cannot be mitigated with this technique - most of the highly critical vulnerabilities in Drupal's past would have been mitigated with this method.

"I am proud that we can advance Drupal's commitment to enterprise-grade security," said Heather Rocker, Executive Director of the Drupal Association. "The Drupal Steward program and its security protections should give the world the confidence to build the next generation of digital experiences on open source technology."

Drupal sites hosted with the Drupal Steward Founding Partners Acquia and Pantheon will be directly protected by those partners. For sites not hosted by the Drupal Steward founding partners, Drupal site owners will be able to subscribe to the Community tier of the Drupal Steward program directly through the Drupal Association at an affordable cost, with discounts provided to clients of Drupal Association supporting partners with a record of contribution to the project in the form of time, talent, or treasure.

Learn more about Drupal Steward

For complete details about the Drupal Steward program, including how to sign up - please visit https://www.drupal.org/security-team/steward

Powered by a global community

Drupal is a true open source project, leveraging the expertise of tens of thousands of developers around the world. Drupal has a proven track record for strong security practices, with a strong belief that the transparency of open source leads to more secure software.

About Drupal and the Drupal Association

Drupal is the open source content management software used by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization dedicated to accelerating the Drupal software project, fostering the community, and supporting its growth.


For more information contact secwg-partnerships@association.drupal.org 

Categories: FLOSS Project Planets

Amazee Labs: Join us at DrupalCon Global

Planet Drupal - Thu, 2020-07-09 06:29
<img src="https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/AL-Going-to-DrupalCon-Global-Blogs.jpg?h=994a2424&amp;itok=j5e9gWaA" width="1120" height="630" alt="Join us at DrupalCon Global " title="Join us at DrupalCon Global " class="image-style-leading-image" /> DrupalCon Global 2020 is just a few days away, and we’re excitedly prepping up for what’s sure to be a virtual event like nothing the community has seen before. To say the least, it’s been a strange few months for everyone on the planet, but we at Amazee Labs think nothing exemplifies the resilient and persistent spirit of the open-source community like the innovative skills and organizational determination it took to bring DrupalCon Global 2020 and all its global attendees together.
Categories: FLOSS Project Planets

Codementor: Big Data: 70 Increíbles Fuentes de Datos Gratuitas que Debes Conocer para 2020

Planet Python - Thu, 2020-07-09 05:40
ay miles de conjuntos de datos gratuitos disponibles en línea website, listos para ser analizados y visualizados por cualquier persona. Aquí hemos reunido 70 fuentes de datos gratuitas para 2020 sobre gobierno, delincuencia, salud, datos financieros y económicos, marketing y redes sociales, periodismo y medios, bienes raíces, directorio, revisión de empresas, y más.
Categories: FLOSS Project Planets

PyCharm: Release: PyCharm 2020.1.3

Planet Python - Thu, 2020-07-09 05:39

PyCharm 2020.1.3 is out with some important bug fixes. Update from within PyCharm (Help | Check for Updates), using the JetBrains Toolbox, or by downloading the new version from our website.


And many more small fixes, see our release notes for details.

Getting latest version

You can update PyCharm by choosing Help | Check for Updates (or PyCharm | Check for Updates on macOS) in the IDE. PyCharm will be able to patch itself to the new version, there should no longer be a need to run the full installer.
If you’re on Ubuntu 16.04 or later, or any other Linux distribution that supports snap, you should not need to upgrade manually, you’ll automatically receive the new version.

Categories: FLOSS Project Planets

PSF GSoC students blogs: GSoC Week 6: Begin the Phase 2

Planet Python - Thu, 2020-07-09 05:07
What I did this week?

As mentioned I worked on refactoring output_engine due to its increasing size. It will now be easy to maintain although I have not sumbitted a PR because I need the latest PR by Niraj to work and I'm waiting to get that merged. As soon as that gets merged I'll file a 2 PRs one refactoring output_engine and other adding the exact path to the extracted files. That issue was also on our priority list. But I have not added that in our HTML and we are just storing that for now and it will be covered in the future updates.

What is coming up next?

For now I'll be researching on my future goals and I'll work to update the HTML reports according to the Triage stuff and according to the new Paths that the user might want to see in their HTML reports. New HTML design will contain changes acccording to the new Triage stuff that Niraj kamdar has added  Like New Found, Mitigated, Ignored etc. 

Have I got stuck anywhere?

I'm stuck because I need the latest PR by Niraj to get merged in order to work Although I have started and completed my work on top of the Niraj's Latest PR but That PR might need some changes and I'll need to incorporate those changes in my PR too. 

Categories: FLOSS Project Planets

Fixing a common antipattern when loading translations in Qt

Planet KDE - Thu, 2020-07-09 05:00

TL;DR: If you choose a default translation in your Qt application based on a locale name like this:

QTranslator myappTranslator; myappTranslator.load("myapp_" + QLocale::system().name());

then please change it to:

QTranslator myappTranslator; myappTranslator.load(QLocale(), "myapp", "_");

Some of your users (me!) will be thankful that your application appears in the same language as the rest of their system.


I’m a Polish guy working with computers, mostly on Windows. However, the lingua franca of the IT industry is English, so every time I see a tutorial for some dev tool, it’s in that language. To lessen the burden of decoding which menu entry in the tutorial corresponds to which menu entry on my PC I decided to run the system with an English display language. I still want the rest of the i18n-related stuff (date format, keyboard, currency etc.) to be in Polish however.

That’s why my system has Polish locale and English display language. This leads to a problem:

As you can see, Thunderbird and Windows Settings show up in English but Qt Linguist is encrypted with some overengineered Slavic cipher (aka Polish language). What I further noticed, is that this incorrect language selection is particularly prevalent in Qt-based applications. Subsequent digging revealed that this antipattern is widespread in Qt world, see the relevant GitHub search (requires login).

The Root Cause

My investigation made me think: Why do Qt users keep doing this wrong?

It turns out that it’s what the documentation tells them to do! See, the first time a Qt user wants to do i18n they are led to the Internationalization landing page which contained the following section in the middle:

Which in case of my system is unfortunately incorrect. QLocale::system().name() will return "pl_PL" which is not what I want. You should use the other overload of QTranslator::load() that consults the list of user’s preferred display languages (yes, it’s a list) and chooses the correct one.

To be fair to Qt’s docs, they actually tell you to use it but you need to navigate to the QTranslator docs and scroll to the bottom of the section about the first QTranslator::load() overload:

Not very discoverable

I personally believe that we shouldn’t blame the developers if they use the first thing they see prominently featured on the subsystem landing page. They don’t want to delve into intricacies of Qt’s i18n support, they have other problems to solve with their application (also, developers are lazy, at least, I am).

That’s why it’s so important to make sure that users are taught best practice the first time they are dealing with a concept. Or at least they are explicitly warned that they should do things differently in a real-world code (with examples).

The Fix

The obvious fix is to change the offending line as I show in the beginning of the post. This won’t however prevent new users from making this mistake again. The real fix is thus to fix the Qt documentation. And I did just that:


Oh, and I fixed some applications too:


The Call

If you are a maintainer of Qt-based application, please take a look in your codebase and see whether you use this antipattern. If you won’t fix it, and I happen to use your application, be prepared to deal with a change request at some point. 🙂

About KDAB

If you like this blog and want to read similar articles, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post Fixing a common antipattern when loading translations in Qt appeared first on KDAB.

Categories: FLOSS Project Planets

Enrico Zini: Mime type associations

Planet Debian - Thu, 2020-07-09 04:20

The last step of my laptop migration was to fix mime type associations, that seem to associate opening file depending on whatever application was installed last, phases of the moon, and what option is the most annoying.

The state of my system after a fresh install, is that, for application/pdf, xdg-open (used for example by pcmanfm) runs inkscape, and run-mailcap (used for example by neomutt) runs the calibre ebook viewer.

It looks like there are at least two systems to understand, debug and fix, instead of one.


This comes from package xdg-utils, and works using .desktop files:

# This runs inkscape $ xdg-open file.pdf

There is a tool called xdg-mime that queries what .desktop file is associated with a given mime type:

$ xdg-mime query default application/pdf inkscape.desktop

You can use xdg-mime default to change an association, and it works nicely:

$ xdg-mime default org.gnome.Evince.desktop application/pdf $ xdg-mime query default application/pdf org.gnome.Evince.desktop

However, if you accidentally mistype the name of the .desktop file, it won't complain and it will silently reset the association to the arbitrary default:

$ xdg-mime default org.gnome.Evince.desktop application/pdf $ xdg-mime query default application/pdf org.gnome.Evince.desktop $ xdg-mime default evince.desktop application/pdf $ echo $? 0 $ xdg-mime query default application/pdf inkscape.desktop

You can use a GUI like xfce4-mime-settings from the xfce4-settings package to perform the same kind of changes avoiding typing mistakes.

The associations seem to be saved in ~/.config/mimeapps.list


This comes from the package mime-support

You can test things by running it using --norun:

$ run-mailcap --norun file.pdf ebook-viewer file.pdf

run-mailcap uses the ~/.mailcap and /etc/mailcap to map mime types to commands. This is what's in the system default:

$ grep application/pdf /etc/mailcap application/pdf; ebook-viewer %s; test=test -n "$DISPLAY" application/pdf; calibre %s; test=test -n "$DISPLAY" application/pdf; gimp-2.10 %s; test=test -n "$DISPLAY" application/pdf; evince %s; test=test -n "$DISPLAY"

To fix this, I copypasted the evince line into ~/.mailcap, and indeed it gets used:

$ run-mailcap --norun file.pdf evince file.pdf

There is a /etc/mailcap.order file providing a limited way to order entries in /etc/mailcap, but it can only be manipulated system-wide, and cannot be used for user preferences.

Sadly, this means that if a package changes its mailcap invocation because of, say, a security issue in the former one, the local override will never get fixed.

I am really not comfortable about that. As a workaround, I put this in my ~/.mailcap:

application/pdf; xdg-open %s && sleep 0.3s; test=test -n "$DISPLAY"

The sleep 0.3s is needed because xdg-open exits right after starting the program, and when invoked by mutt it means that mutt could delete the attachment before evince has a chance to open it. I had to use the same workaround for sensible-browser, since the same happens when a browser opens a document in an existing tab.

I wonder if there is any reason run-mailcap could not be implemented as a wrapper to xdg-open.

I reported #964723 elaborating on these thoughts.

Categories: FLOSS Project Planets

Python Bytes: #189 What does str.strip() do? Are you sure?

Planet Python - Thu, 2020-07-09 04:00
<p>Sponsored by us! Support our work through:</p> <ul> <li>Our <a href="https://training.talkpython.fm/"><strong>courses at Talk Python Training</strong></a></li> <li><a href="https://t.co/AKfVKcveg6?amp=1"><strong>Brian’s pytest book</strong></a></li> </ul> <p><strong>Brian #1:</strong> <a href="https://blog.ram.rachum.com/post/621791438475296768/improving-python-exception-chaining-with"><strong>Improving Python exception chaining with raise-from</strong></a></p> <ul> <li>Ram Rachum</li> <li>Python3 has a change called <a href="https://www.python.org/dev/peps/pep-3134/">PEP 3134: Exception Chaining and Embedded Tracebacks</a></li> <li>It should be used more than it is.</li> <li>If an exception is raised from an except clause, it could be because: <ul> <li>something unexpected happened</li> <li>“An exception was raised, and we decided to replace it with a different exception that will make more sense to whoever called this code. Maybe the new exception will make more sense because we’re giving a more helpful error message. Or maybe we’re using an exception class that’s more relevant to the problem domain, and whoever’s calling our code could wrap the call with an except clause that’s tailored for this failure mode.”</li> </ul></li> <li>If it’s the second case, you should change your code to something like this:</li> </ul> <pre><code> try: [HTML_REMOVED] except ExpectedExceptionType as e: raise BetterException('Better explanation') from e </code></pre> <ul> <li>It’s the <code>from e</code> that does the magic.</li> <li>And now instead of getting <code>During handling of the above exception, another exception occurred:</code></li> <li>You get: <code>The above exception was the direct cause of the following exception:</code></li> <li>“That’s how you know you have a case of a friendly wrapping of an exception.”</li> </ul> <p><strong>Michael #2:</strong> <a href="https://www.datapane.com/"><strong>Create and publish interactive reports in Python</strong></a></p> <ul> <li>via Tim Pogue</li> <li>Datapane is an open source framework which makes it easy to turn scripts and notebooks into interactive reports. </li> <li>Free for individuals, paid(?) for teams</li> <li>Build reports in Python and deploy scripts and notebooks as self-service reporting tools.</li> <li><strong>Analyze data in your own tools:</strong> Write code and analyze data in your own editor or environment, whether its Jupyter, Colab, or Airflow.</li> <li><strong>Build reports in code:</strong> Datapane's framework makes it easy to create rich reports from DataFrames, Markdown, and visualization libraries, such as Altair.</li> <li><strong>Publish and share:</strong> Export as standalone HTML files, or publish reports to Datapane.com for free, where they can be shared and embedded.</li> <li>Add forms to filter / drive the report</li> <li>Everything in Datapane is an API. Deploy scripts and generate reports from your server, GitHub, Airflow, or CI system.</li> <li>Check out <a href="https://www.datapane.com/gallery/">the gallery</a>.</li> </ul> <p><strong>Brian #3:</strong> <a href="https://nedbatchelder.com/blog/202006/pickles_nine_flaws.html"><strong>Pickle’s nine flaws</strong></a></p> <ul> <li>Ned Batchelder</li> <li>Instead of “never use pickle”, Ned says “only use pickle if you are OK with it’s nine flaws”</li> <li>The flaws <ul> <li>Insecure : Malicious pickles can get the unpickler to run bad code</li> <li>Old pickles look like old code : Any changes to your data structures might break your ability to read old pickles</li> <li>Implicit: All data is serialized as class objects, even if that’s not what you want.</li> <li>Over-serializes: Serializes everything in your objects, even things like cached computation</li> <li><code>__init__</code> isn’t called : during unpickling, even if it really should be for your situation</li> <li>Python only : for the most part, it’s not something you can use with other languages</li> <li>Unreadable: binary, so good luck debugging problems</li> <li>Appears to pickle code: but doesn’t really. Keeping a list of functions or classes? It’ll get pickled as names and get bound to a function/class matching the name during unpickling.</li> <li>Slow</li> </ul></li> <li>Some of it you can work around, but then, why?</li> <li>Alternatives: JSON, marshmallow, cattrs, protocol buffers, … </li> </ul> <p><strong>Michael #4:</strong> <a href="https://www.python.org/dev/peps/pep-0602/"><strong>PEP 602 -- Annual Release Cycle for Python</strong></a></p> <ul> <li>by Łukasz Langa</li> <li>Status accepted</li> <li>This PEP proposes that Python 3.X.0 will be developed for around 17 months: <ul> <li>The first <em>five months</em> overlap with Python 3.(X-1).0's beta and release candidate stages and are thus unversioned.</li> <li>The next <em>seven months</em> are spent on versioned alpha releases where both new features are incrementally added and bug fixes are included.</li> <li>The following <em>three months</em> are spent on four versioned beta releases where <strong>no new features</strong> can be added but bug fixes are still included.</li> <li>The final <em>two months</em> are spent on two release candidates (or more, if necessary) and conclude with the release of the final release of Python 3.X.0.</li> </ul></li> <li>Annual release cadence: Feature development of Python 3.(X+1).0 starts as soon as Python 3.X.0 Beta 1 is released. This creates a twelve month delta between major Python versions.</li> <li>This change provides the following advantages: <ul> <li>makes releases smaller: since doubling the cadence doesn't double our available development resources, consecutive releases are going to be smaller in terms of features;</li> <li>puts features and bug fixes in hands of users sooner;</li> <li>creates a more gradual upgrade path for users, by decreasing the surface of change in any single release;</li> <li>creates a predictable calendar for releases where the final release is always in October (so after the annual core sprint), and the beta phase starts in late May (so after PyCon US sprints), which is especially important for core developers who need to plan to include Python involvement in their calendar;</li> </ul></li> </ul> <p><strong>Brian #5:</strong> <strong>More git Resources:</strong> </p> <ul> <li><p><a href="https://pythonbytes.fm/187">On episode 187</a> we talked about Oh Sh*t, Git!, a zine by Julia Evans I mentioned that I was concerned about buying it for a team due to the mild swearing. John Place reached out to tell us there’s a non-swearing version:</p> <ul> <li><a href="https://gumroad.com/l/dangit-git">Dangit, git!</a>, the zine.</li> </ul></li> <li><p>Also both of these are inspired by two websites by Katie Sylor-Miller:</p> <ul> <li><a href="http://dangitgit.com/">dangitgit.com</a></li> <li><a href="https://ohshitgit.com/">ohshitgit.com</a></li> <li>These are free websites with “something went wrong, how to I fix it” solutions.</li> <li>All issues have titles that are links/anchors, so you can send someone a link if they ask you a question of how to fix something with git, and hopefully they can figure it out themselves sometime.</li> </ul></li> <li><p>Also <a href="http://ndpsoftware.com/git-cheatsheet.html">Git Cheatsheet</a> </p> <ul> <li>Not just a pdf</li> <li>An interactive single page site that is, for one, beautifully designed.</li> <li>There’s 5 columns: Stash, Workspace, Index, Local Repo, Upstream Repo</li> <li>Hover over a column and it shows you git commands that affect that part and flows to other columns.</li> <li>Hover over a command and the description pops up at the bottom.</li> <li>The visual is great for reinforcing how actions move data between different parts of a repository, and a great way to teach people to have that mental model that git is not just your repo, it’s all of these components working together.</li> </ul></li> <li><p>Lastly, <a href="http://justinhileman.info/article/git-pretty/git-pretty.png">git-pretty</a></p> <ul> <li>Similar goals as the dangit and ohsh*t offerings, this is a single page png flowchart that starts with “so you have a mess on your hands” and asks a bunch of questions to funnel you to how to fix it. A fun thing to print out and pin to your wall.</li> </ul></li> </ul> <p><strong>Michael #6:</strong> <a href="https://www.python.org/dev/peps/pep-0616/"><strong>PEP 616 -- String methods to remove prefixes and suffixes</strong></a></p> <ul> <li>Dennis Sweeney</li> <li>Status: Accepted</li> <li>Question: What does this return? <code>“saturday is the 1st".strip('st')</code> </li> <li>Answer: <code>aturday is the 1</code></li> <li>If you expected it to remove the string <code>st</code>, well, no. That’s PEP 616.</li> <li>Add two new methods, <code>removeprefix()</code> and <code>removesuffix()</code>, to the APIs of Python's various string objects. These methods would remove a prefix or suffix (respectively) from a string, if present, and would be added to Unicode str objects, binary bytes and bytearray objects, and collections.UserString.</li> </ul> <p>Extras:</p> <p>Michael: </p> <ul> <li><a href="https://freecontent.manning.com/register-for-livemanning-python/">Manning conference Python Bytes event</a> </li> <li><a href="https://twitter.com/mkennedy/status/1276193238710390789">Michael's 10 tips for web dev PyCon recording out</a></li> <li><a href="https://talkpython.fm/humble2020">Learn Python Humble Bundle</a></li> <li>Telegram bots <ul> <li>by Abhishek Pednekar</li> <li><a href="https://t.me/PythonBytesBot">Python Bytes</a></li> <li>https://t.me/TalkPythonBot</li> </ul></li> </ul> <p>Joke:</p> <p>Karen Chee (@karencheee):</p> <ul> <li><strong>you:</strong> A famous engineer / inventor is coming over for dinner tonight, want to join us?</li> <li><strong>me:</strong> Sure, who is it?</li> <li><strong>you:</strong> His name is Rube Goldberg</li> <li><strong>me:</strong> That name rings a bell, which sets off a trap that undoes a buckle and releases a ball that rolls down a pipe and …</li> </ul>
Categories: FLOSS Project Planets

pythonwise: Using module __dir__ and __getattr__ for configuration

Planet Python - Thu, 2020-07-09 03:52
PEP 562 added support for module level __dir__ and __getitem__. 
  • __dir__ is called when the built-in dir function is called on the module
  • __getattr__ is called when an attribute is not found via the regular attribute lookup
Let's use this to build an environment based configuration module. 
  • Conviruation values has a value, environment key and a function to convert from str to right type
    • I'm going to use dataclasses and populate values from environment in __post_init__
    • Complex data types (such as list) should be JSON encoded in the environment variables
  • All configuration values with start with the c_ prefix
  • __dir__ will return a list configuration variables without the c_ prefix
  • __getattr__ will add the c_ prefix and will look for the varialbes in globals
We're adding c_ prefix and removing it to bypass the regular attribute lookup mechanism. If we'll call a variable http_port and user will write config.http_port, our __dir__ function won't be called.
Here's the code
Categories: FLOSS Project Planets

Enrico Zini: Laptop migration

Planet Debian - Thu, 2020-07-09 03:34

My laptop battery started to explode in slow motion. HP requires 10 business days to repair my laptop under warranty, and I cannot afford that length of downtime.

Alternatively, HP quoted me 375€ + VAT for on-site repairs, which I tought was very funny.

For 376.55€ + VAT, which is pretty much exactly the same amount, I bought instead a refurbished ThinkPad X240 with a dual-core I5, 8G of RAM, 250G SSD, and a 1920x1080 IPS display, to use as a spare while my laptop is being repaired. I'd like to thank HP for giving me the opportunity to own a ThinkPad.

Since I'm migrating all my system to the spare and then (hopefully) back, I'm documenting what I need to be fully productive on new hardware.

Install Debian

A basic Debian netinst with no tasks selected is good enough to get going.

Note that if wifi worked in Debian Installer, it doesn't mean that it will work in the minimal system it installed. See here for instructions on quickly bringing up wifi on a newly installed minimal system.

Copy /home

A simple tar of /home is all I needed to copy my data over.

A neat way to do it was connecting the two laptops with an ethernet cable, and using netcat:

# On the source tar -C / -zcf - home | nc -l -p 12345 -N # On the target nc 12345 | tar -C / -zxf -

Since the data travel unencrypted in this way, don't do it over wifi.

Install packages

I maintain a few simple local metapackages that depend on the packages I usually used.

I could just install those and let apt bring in their dependencies.

For the build dependencies of the programs I develop, I use mk-build-deps from the devscripts package to create metapackages that make sure they are installed.

Here's an extract from debian/control of the metapackage:

Source: enrico Section: admin Priority: optional Maintainer: Enrico Zini <enrico@debian.org> Build-Depends: debhelper (>= 11) Standards-Version: Package: enrico Section: admin Architecture: all Depends: mc, mmv, moreutils, powertop, syncmaildir, notmuch, ncdu, vcsh, ddate, jq, git-annex, eatmydata, vdirsyncer, khal, etckeeper, moc, pwgen Description: Enrico's working environment Package: enrico-devel Section: devel Architecture: all Depends: git, python3-git, git-svn, gitk, ansible, fabric, valgrind, kcachegrind, zeal, meld, d-feet, flake8, mypy, ipython3, strace, ltrace Description: Enrico's development environment Package: enrico-gui Section: x11 Architecture: all Depends: xclip, gnome-terminal, qalculate-gtk, liferea, gajim, mumble, sm, syncthing, virt-manager Recommends: k3b Description: Enrico's GUI environment Package: enrico-sanity Section: admin Architecture: all Conflicts: libapache2-mod-php, libapache2-mod-php5, php5, php5-cgi, php5-fpm, libapache2-mod-php7.0, php7.0, libphp7.0-embed, libphp-embed, libphp5-embed Description: Enrico's sanity Metapackage with a list of packages that I do not want anywhere near my system. System-wide customizations

I tend to avoid changing system-wide configuration as much as possible, so copying over /home and installing packages takes care of 99% of my needs.

There are a few system-wide tweaks I cannot do without:

  • setup postfix to send mail using my mail server
  • copy Network Manager system connections files in /etc/NetworkManager/system-connections/
  • update-alternatives --config editor

For postfix, I have a little ansible playbook that takes care of it.

Network Manager system connections need to be copied manually: a plain copy and a systemctl restart network-manager are enough. Note that Network Manager will ignore the files unless their owner and permissions are what it expects.

Fine tuning

Comparing the output of dpkg --get-selections between the old and the new system might highlight packages manually installed in a hurry and not added to the metapackages.

Finally, what remains is fixing the sad state of mimetype associations, which seem to associate opening file depending on whatever application was installed last, phases of the moon, and what option is the most annoying.

Currently on my system, PDFs are opened in inkscape by xdg-open and in calibre by run-mailcap. Let's see how long it takes to figure this one out.

Categories: FLOSS Project Planets

Agaric Collective: Drupal migrations reference: List of properties per content entity

Planet Drupal - Thu, 2020-07-09 00:30

In a previous article we explained the syntax used to write Drupal migrations. When migrating into content entities, these define several properties that can be included in the process section to populate their values. For example, when importing nodes you can specify the title, publication status, creation date, etc. In the case of users, you can set the username, password, timezone, etc. Finding out which properties are available for an entity might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of properties available in content entities provided by Drupal core and some contributed modules.

For each entity we will present: the module that provides it, the class that defines it, and the available properties. For each property we will list its name, field type, a description, and a note if the field allows unlimited values (i.e. it has an unlimited cardinality). The list of properties available for a content entity depend on many factors. For example, if the entity is revisionable (e.g. revision_default), translatable (e.g. langcode), or both (e.g. revision_translation_affected). The modules that are enabled on the site can also affect the available properties. For instance, if the “Workspaces” module is installed, it will add a workspace property to many content entities. This reference assumes that Drupal was installed using the standard installation profile and all modules that provide content entities are enabled.

It is worth noting that entity properties are divided in two categories: base field definitions and field storage configurations. Base field configurations will always be available for the entity. On the other hand, the presence of field storage configurations will depend on various factors. For one, they can only be added to fieldable entities. Attaching the fields to the entity can be done manually by the user, by a module, or by an installation profile. Again, this reference assumes that Drupal was installed using the standard installation profile. Among other things, it adds a user_picture image field to the user entity and body, comment, field_image, and field_tags fields to the node entity. For entities that can have multiple bundles, not all properties provided by the field storage configurations will be available in all bundles. For example, with the standard installation profile all content types will have a body field associated with it, but only the article content type has the field_image, and field_tags fields. If subfields are available for the field type, you can migrate into them.

Content (Node) entity

Module: Node (Drupal Core)
Class: Drupal\node\Entity\Node
Related article: Writing your first Drupal migration

List of base field definitions:

  1. nid: (integer) The node ID.
  2. uuid: (uuid) The node UUID.
  3. vid: (integer) Revision ID.
  4. langcode: (language) Language code (e.g. en).
  5. type: (entity_reference to node_type) Content type machine name.
  6. revision_timestamp: (created) The time that the current revision was created.
  7. revision_uid: (entity_reference to user) The user ID of the author of the current revision.
  8. revision_log: (string_long) Briefly describe the changes you have made.
  9. status: (boolean) Node published when set to TRUE.
  10. uid: (entity_reference to user) The user ID of the content author.
  11. title: (string) Title.
  12. created: (created) The time that the node was created.
  13. changed: (changed) The time that the node was last edited.
  14. promote: (boolean) Node promoted to front page when set to TRUE.
  15. sticky: (boolean) Node sticky at top of lists when set to TRUE.
  16. default_langcode: (boolean) A flag indicating whether this is the default translation.
  17. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  18. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  19. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

List of field storage configurations:

  1. body: text_with_summary field.
  2. comment: comment field.
  3. field_image: image field.
  4. field_tags: entity_reference field.
User entity

Module: User (Drupal Core)
Class: Drupal\user\Entity\User
Related articles: Migrating users into Drupal - Part 1 and Migrating users into Drupal - Part 2

List of base field definitions:

  1. uid: (integer) The user ID.
  2. uuid: (uuid) The user UUID.
  3. langcode: (language) The user language code.
  4. preferred_langcode: (language) The user's preferred language code for receiving emails and viewing the site.
  5. preferred_admin_langcode: (language) The user's preferred language code for viewing administration pages.
  6. name: (string) The name of this user.
  7. pass: (password) The password of this user (hashed).
  8. mail: (email) The email of this user.
  9. timezone: (string) The timezone of this user.
  10. status: (boolean) Whether the user is active or blocked.
  11. created: (created) The time that the user was created.
  12. changed: (changed) The time that the user was last edited.
  13. access: (timestamp) The time that the user last accessed the site.
  14. login: (timestamp) The time that the user last logged in.
  15. init: (email) The email address used for initial account creation.
  16. roles: (entity_reference to user_role) The roles the user has. Allows unlimited values.
  17. default_langcode: (boolean) A flag indicating whether this is the default translation.

List of field storage configurations:

  1. user_picture: image field.
Taxonomy term entity

Module: Taxonomy (Drupal Core)
Class: Drupal\taxonomy\Entity\Term
Related article: Migrating taxonomy terms and multivalue fields into Drupal

List of base field definitions:

  1. tid: (integer) The term ID.
  2. uuid: (uuid) The term UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) The term language code.
  5. vid: (entity_reference to taxonomy_vocabulary) The vocabulary to which the term is assigned.
  6. revision_created: (created) The time that the current revision was created.
  7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
  8. revision_log_message: (string_long) Briefly describe the changes you have made.
  9. status: (boolean) Published.
  10. name: (string) Name.
  11. description: (text_long) Description.
  12. weight: (integer) The weight of this term in relation to other terms.
  13. parent: (entity_reference to taxonomy_term) The parents of this term. Allows unlimited values.
  14. changed: (changed) The time that the term was last edited.
  15. default_langcode: (boolean) A flag indicating whether this is the default translation.
  16. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  17. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  18. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
File entity

Module: File (Drupal Core)
Class: Drupal\file\Entity\File
Related articles: Migrating files and images into Drupal, Migrating images using the image_import plugin, and Migrating images using the image_import plugin

List of base field definitions:

  1. fid: (integer) The file ID.
  2. uuid: (uuid) The file UUID.
  3. langcode: (language) The file language code.
  4. uid: (entity_reference to user) The user ID of the file.
  5. filename: (string) Name of the file with no path components.
  6. uri: (file_uri) The URI to access the file (either local or remote).
  7. filemime: (string) The file's MIME type.
  8. filesize: (integer) The size of the file in bytes.
  9. status: (boolean) The status of the file, temporary (FALSE) and permanent (TRUE).
  10. created: (created) The timestamp that the file was created.
  11. changed: (changed) The timestamp that the file was last changed.
Media entity

Module: Media (Drupal Core)
Class: Drupal\media\Entity\Media

List of base field definitions:

  1. mid: (integer) The media ID.
  2. uuid: (uuid) The media UUID.
  3. vid: (integer) Revision ID.
  4. langcode: (language) Language code (e.g. en).
  5. bundle: (entity_reference to media_type) Media type.
  6. revision_created: (created) The time that the current revision was created.
  7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
  8. revision_log_message: (string_long) Briefly describe the changes you have made.
  9. status: (boolean) Published.
  10. uid: (entity_reference to user) The user ID of the author.
  11. name: (string) Name.
  12. thumbnail: (image) The thumbnail of the media item.
  13. created: (created) The time the media item was created.
  14. changed: (changed) The time the media item was last edited.
  15. default_langcode: (boolean) A flag indicating whether this is the default translation.
  16. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  17. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  18. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

List of field storage configurations:

  1. field_media_audio_file: file field.
  2. field_media_document: file field.
  3. field_media_image: image field.
  4. field_media_oembed_video: string field.
  5. field_media_video_file: file field.
Comment entity

Module: Comment (Drupal Core)
Class: Drupal\comment\Entity\Comment

List of base field definitions:

  1. cid: (integer) The comment ID.
  2. uuid: (uuid) The comment UUID.
  3. langcode: (language) The comment language code.
  4. comment_type: (entity_reference to comment_type) The comment type.
  5. status: (boolean) Published.
  6. uid: (entity_reference to user) The user ID of the comment author.
  7. pid: (entity_reference to comment) The parent comment ID if this is a reply to a comment.
  8. entity_id: (entity_reference to node) The ID of the entity of which this comment is a reply.
  9. subject: (string) Subject.
  10. name: (string) The comment author's name.
  11. mail: (email) The comment author's email address.
  12. homepage: (uri) The comment author's home page address.
  13. hostname: (string) The comment author's hostname.
  14. created: (created) The time that the comment was created.
  15. changed: (changed) The time that the comment was last edited.
  16. thread: (string) The alphadecimal representation of the comment's place in a thread, consisting of a base 36 string prefixed by an integer indicating its length.
  17. entity_type: (string) The entity type to which this comment is attached.
  18. field_name: (string) The field name through which this comment was added.
  19. default_langcode: (boolean) A flag indicating whether this is the default translation.

List of field storage configurations:

  1. comment_body: text_long field.
Aggregator feed entity

Module: Aggregator (Drupal Core)
Class: Drupal\aggregator\Entity\Feed

List of base field definitions:

  1. fid: (integer) The ID of the aggregator feed.
  2. uuid: (uuid) The aggregator feed UUID.
  3. langcode: (language) The feed language code.
  4. title: (string) The name of the feed (or the name of the website providing the feed).
  5. url: (uri) The fully-qualified URL of the feed.
  6. refresh: (list_integer) The length of time between feed updates. Requires a correctly configured cron maintenance task.
  7. checked: (timestamp) Last time feed was checked for new items, as Unix timestamp.
  8. queued: (timestamp) Time when this feed was queued for refresh, 0 if not queued.
  9. link: (uri) The link of the feed.
  10. description: (string_long) The parent website's description that comes from the element in the feed.
  11. image: (uri) An image representing the feed.
  12. hash: (string) Calculated hash of the feed data, used for validating cache.
  13. etag: (string) Entity tag HTTP response header, used for validating cache.
  14. modified: (timestamp) When the feed was last modified, as a Unix timestamp.
Aggregator feed item entity

Module: Aggregator (Drupal Core)
Class: Drupal\aggregator\Entity\Item

List of base field definitions:

  1. iid: (integer) The ID of the feed item.
  2. langcode: (language) The feed item language code.
  3. fid: (entity_reference to aggregator_feed) The aggregator feed entity associated with this item.
  4. title: (string) The title of the feed item.
  5. link: (uri) The link of the feed item.
  6. author: (string) The author of the feed item.
  7. description: (string_long) The body of the feed item.
  8. timestamp: (created) Posted date of the feed item, as a Unix timestamp.
  9. guid: (string_long) Unique identifier for the feed item.
Custom block entity

Module: Custom Block (Drupal Core)
Class: Drupal\block_content\Entity\BlockContent

List of base field definitions:

  1. id: (integer) The custom block ID.
  2. uuid: (uuid) The custom block UUID.
  3. revision_id: (integer) The revision ID.
  4. langcode: (language) The custom block language code.
  5. type: (entity_reference to block_content_type) The block type.
  6. revision_created: (created) The time that the current revision was created.
  7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
  8. revision_log: (string_long) The log entry explaining the changes in this revision.
  9. status: (boolean) Published.
  10. info: (string) A brief description of your block.
  11. changed: (changed) The time that the custom block was last edited.
  12. reusable: (boolean) A boolean indicating whether this block is reusable.
  13. default_langcode: (boolean) A flag indicating whether this is the default translation.
  14. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  15. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  16. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

List of field storage configurations:

  1. body: text_with_summary field.
Contact message entity

Module: Contact (Drupal Core)
Class: Drupal\contact\Entity\Message

List of base field definitions:

  1. uuid: (uuid) The message UUID.
  2. langcode: (language) The message language code.
  3. contact_form: (entity_reference to contact_form) The ID of the associated form.
  4. name: (string) The name of the person that is sending the contact message.
  5. mail: (email) The email of the person that is sending the contact message.
  6. subject: (string) Subject.
  7. message: (string_long) Message.
  8. copy: (boolean) Whether to send a copy of the message to the sender.
  9. recipient: (entity_reference to user) The ID of the recipient user for personal contact messages.
Content moderation state entity

Module: Content Moderation (Drupal Core)
Class: Drupal\content_moderation\Entity\ContentModerationState

List of base field definitions:

  1. id: (integer) ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) Language.
  5. uid: (entity_reference to user) The username of the entity creator.
  6. workflow: (entity_reference to workflow) The workflow the moderation state is in.
  7. moderation_state: (string) The moderation state of the referenced content.
  8. content_entity_type_id: (string) The ID of the content entity type this moderation state is for.
  9. content_entity_id: (integer) The ID of the content entity this moderation state is for.
  10. content_entity_revision_id: (integer) The revision ID of the content entity this moderation state is for.
  11. default_langcode: (boolean) A flag indicating whether this is the default translation.
  12. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  13. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
URL alias entity

Module: Path alias (Drupal Core)
Class: Drupal\path_alias\Entity\PathAlias

List of base field definitions:

  1. id: (integer) ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) Language.
  5. path: (string) The path that this alias belongs to.
  6. alias: (string) An alias used with this path.
  7. status: (boolean) Published.
  8. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  9. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
Shortcut link entity

Module: Shortcut (Drupal Core)
Class: Drupal\shortcut\Entity\Shortcut

List of base field definitions:

  1. id: (integer) The ID of the shortcut.
  2. uuid: (uuid) The UUID of the shortcut.
  3. langcode: (language) The language code of the shortcut.
  4. shortcut_set: (entity_reference to shortcut_set) The bundle of the shortcut.
  5. title: (string) The name of the shortcut.
  6. weight: (integer) Weight among shortcuts in the same shortcut set.
  7. link: (link) The location this shortcut points to.
  8. default_langcode: (boolean) A flag indicating whether this is the default translation.
Workspace entity

Module: Workspaces (Drupal Core)
Class: Drupal\workspaces\Entity\Workspace

List of base field definitions:

  1. id: (string) The workspace ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. uid: (entity_reference to user) The workspace owner.
  5. label: (string) The workspace name.
  6. parent: (entity_reference to workspace) The parent workspace.
  7. changed: (changed) The time that the workspace was last edited.
  8. created: (created) The time that the workspace was created.
  9. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
Custom menu link entity

Module: Custom Menu Links (Drupal Core)
Class: Drupal\menu_link_content\Entity\MenuLinkContent

List of base field definitions:

  1. id: (integer) The entity ID for this menu link content entity.
  2. uuid: (uuid) The content menu link UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) The menu link language code.
  5. bundle: (string) The content menu link bundle.
  6. revision_created: (created) The time that the current revision was created.
  7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
  8. revision_log_message: (string_long) Briefly describe the changes you have made.
  9. enabled: (boolean) A flag for whether the link should be enabled in menus or hidden.
  10. title: (string) The text to be used for this link in the menu.
  11. description: (string) Shown when hovering over the menu link.
  12. menu_name: (string) The menu name. All links with the same menu name (such as "tools") are part of the same menu.
  13. link: (link) The location this menu link points to.
  14. external: (boolean) A flag to indicate if the link points to a full URL starting with a protocol, like http:// (1 = external, 0 = internal).
  15. rediscover: (boolean) Indicates whether the menu link should be rediscovered.
  16. weight: (integer) Link weight among links in the same menu at the same depth. In the menu, the links with high weight will sink and links with a low weight will be positioned nearer the top.
  17. expanded: (boolean) If selected and this menu link has children, the menu will always appear expanded. This option may be overridden for the entire menu tree when placing a menu block.
  18. parent: (string) The ID of the parent menu link plugin, or empty string when at the top level of the hierarchy.
  19. changed: (changed) The time that the menu link was last edited.
  20. default_langcode: (boolean) A flag indicating whether this is the default translation.
  21. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  22. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  23. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
Paragraph entity

Module: Paragraphs module
Class: Drupal\paragraphs\Entity\Paragraph
Related article: Introduction to paragraphs migrations in Drupal

List of base field definitions:

  1. id: (integer) ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) The paragraphs entity language code.
  5. type: (entity_reference to paragraphs_type) Paragraph type.
  6. status: (boolean) Published.
  7. created: (created) The time that the Paragraph was created.
  8. parent_id: (string) The ID of the parent entity of which this entity is referenced.
  9. parent_type: (string) The entity parent type to which this entity is referenced.
  10. parent_field_name: (string) The entity parent field name to which this entity is referenced.
  11. behavior_settings: (string_long) The behavior plugin settings
  12. default_langcode: (boolean) A flag indicating whether this is the default translation.
  13. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  14. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  15. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

List of field storage configurations:

  1. field_reusable_paragraph: entity_reference field.
Paragraphs library item entity

Module: Paragraphs Library (part of paragraphs module)
Class: Drupal\paragraphs_library\Entity\LibraryItem

List of base field definitions:

  1. id: (integer) ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. langcode: (language) Language.
  5. revision_created: (created) The time that the current revision was created.
  6. revision_uid: (entity_reference to user) The user ID of the author of the current revision.
  7. revision_log: (string_long) Briefly describe the changes you have made.
  8. status: (boolean) Published.
  9. label: (string) Label.
  10. paragraphs: (entity_reference_revisions) Paragraphs.
  11. created: (created) The time that the library item was created.
  12. changed: (changed) The time that the library item was last edited.
  13. uid: (entity_reference to user) The user ID of the library item author.
  14. default_langcode: (boolean) A flag indicating whether this is the default translation.
  15. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  16. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
  17. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
Profile entity

Module: Profile module
Class: Drupal\profile\Entity\Profile

List of base field definitions:

  1. profile_id: (integer) ID.
  2. uuid: (uuid) UUID.
  3. revision_id: (integer) Revision ID.
  4. type: (entity_reference to profile_type) Profile type.
  5. revision_created: (created) The time that the current revision was created.
  6. revision_user: (entity_reference to user) The user ID of the author of the current revision.
  7. revision_log_message: (string_long) Briefly describe the changes you have made.
  8. status: (boolean) Whether the profile is active.
  9. uid: (entity_reference to user) The user that owns this profile.
  10. is_default: (boolean) Whether this is the default profile.
  11. data: (map) A serialized array of additional data.
  12. created: (created) The time when the profile was created.
  13. changed: (changed) The time when the profile was last edited.
  14. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
  15. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
Available properties for other content entities

This reference includes all core content entities and some provided by contributed modules. The next article will include a reference for Drupal Commerce content entities. That being said, it would be impractical to cover all contributed modules. To get a list of yourself for other content entities, load the entity_type.manager service and call its getFieldStorageDefinitions() method passing the machine name of the entity as a parameter. Although this reference only covers content entities, the same process can be used for configuration entities.

What did you learn in today’s article? Did you know that there were so many entity properties in Drupal core? Were you aware that the list of available properties depend on factors like if the entity is fieldable, translatable, and revisionable? Did you know how to find properties for content entities from contributed modules? Please share your answers in the comments. Also, we would be grateful if you shared this article with your friends and colleagues.

Read more and discuss at agaric.coop.

Categories: FLOSS Project Planets

OSTraining: How to Use the Recaptcha Module in Drupal 8

Planet Drupal - Thu, 2020-07-09 00:00

The reCAPTCHA module for Drupal 8 integrates the reCAPTCHA service provided by Google with your Drupal site. This service provides additional protection by detecting if the user accessing your site is a real person or a robot. 

Keep reading to learn how to use this module!

Categories: FLOSS Project Planets

High DPI update

Planet KDE - Wed, 2020-07-08 23:07

I’d like to share a brief update regarding the state of high DPI support. Since getting a laptop with a 4K screen, I’ve found all sorts of subtle papercuts and have been doing my best to fix them or at least file bug reports. Here’s what’s been fixed recently:

Fixed recently

…And the work continues! Here are the bugs next on my list to investigate and try to fix:

Next up

A lot of the above issues are sort of stretch goals for me as each one requires a great deal of learning before I can even begin to try to put together a halfway-intelligent fix. So feel free to help out if you find this work useful and have relevant skills!

Categories: FLOSS Project Planets

PSF GSoC students blogs: Week 3 Blog Post

Planet Python - Wed, 2020-07-08 20:23

Sorry for the late post.

What i have done this week

During the test for the parse command function, i find that there are long whitespaces that will be parse as package name. So i use shlex to remove long whitespaces.

First use shlex to split into seperate words, and then use space to join them( ' '.join(shlex.split(command)) ), this will remove long whitespaces, tab and line inditations.


After discussion with my mentor, we are now at the final step of the shell script parser which is updating the functions to enable this parser in the tern.

Did i get stuck somewhere?


Categories: FLOSS Project Planets

Matt Layman: Enrolling Students - Building SaaS #64

Planet Python - Wed, 2020-07-08 20:00
In this episode, we worked on a view to enroll students into a grade level for the school year. I added all the context data and used Tailwind to design the form layout to pick from a list of available grade levels. We added a variety of unit tests to prove the correctness. The enrollment page needed three pieces of data in the context to complete the form. We added the student, school_year, and grade_levels data to the context and wrote tests to show the data in there.
Categories: FLOSS Project Planets

Python Engineering at Microsoft: Enhance your Azure Machine Learning experience with the VS Code extension

Planet Python - Wed, 2020-07-08 19:30

Hey Python community! It’s been a while since we’ve last posted about this, but we’re excited to present new capabilities we’ve added to the VS Code Azure Machine Learning (AML) extension. From version 0.6.12 onwards we’ve introduced UI changes and ways to help you manage Datastores, Datasets, and Compute instances all from directly within your favourite editor!

We’re guessing many of you may be reading about Azure ML and the extension for the first time – don’t worry, we’re here to explain!

Azure ML is a machine learning service that provides a wide set of tools and resources for data scientists to build, train, and deploy models. The AML extension is a companion tool to the service which provides a guided experience to help create and manage resources from directly within VS Code. The extension aims to streamline tasks such as running experiments, creating compute targets, and managing environments, without requiring the context-switch from the editor to the browser. Extensions users are enabled to work across their workspaces and interact with their core AML assets via an easy-to-navigate tree view and single-click commands.

You can learn more about getting started with the Azure ML service here. If you’d like to experiment with the extension, you can install it here and read the getting started documentation here!

Datastore Integration

One of the new features we’ve released is support for Datastore registration Datastores are an AML resource that allow you to store connection information to Azure storage services. With Datastores, you no longer have to worry about writing custom storage connectors or hard-code your connection information as environment variables, config objects, or strings in your source.

The AML extension currently supports Azure Blob Storage and Azure File Share datastore types. To enable faster registrations, we’ve designed a set of streamlined input options, such as automatically retrieving your Account Key credentials to authenticate against your Azure storage account.

Register a datastore through the AML extension tree view


Dataset Integration

The AML extension now supports creating both Tabular and File datasetsDatasets can be used to define a consumable object from data in your datastore, local file system, or a remote location; these objects can then be used during experimentation and training tasks.

Create a Tabular or File dataset through the extension tree view


Once you’ve created a Tabular dataset, you can use the extension to preview the first 50 rows of your data. Dataset previews currently support filtering through simple expressions (e.g. search directly for “str” in a string column, or use “> X” in a numeric column).

Preview your tabular datasets and filter column values


In previous releases of the AML extension, we added support to help you train your models in Azure through Experiments. Experiments are made up of your training script, the compute target to run on, and the environment in which you want to run (i.e. what Python packages should be installed). With datasets being introduced, we’ve made it easy for you to use these datasets in your experiment without having to write extra AML SDK code. Right before submitting your experiment, you’re shown a configuration file with a reference to your datasets. In the file you just need to input the script parameter and attach mechanism to use for a File dataset, or the named input you’d like to use for a Tabular dataset.

Dataset usage in experiment run configuration


Compute Instance Integration

AML compute instances are managed VMs that you can configure and use for your ML experimentation. With the VS Code extension creating and managing these compute instances has never been easier! You can view all your workspace’s compute instances and start/stop/restart them through commands in the tree. With a small number of clicks, you can create an SSH-enabled compute instance and then follow our in-editor documentation to easily connect to it via the VS Code Remote SSH extension.

Create a compute instance and connect to it from within VS Code


UI Changes

Something we’ve been hearing for a long time is how the extension UI differs from the Azure ML Studio. In the previous GIFs you may have already noticed the highly consistent design in the extension tree view. We’ve updated each node with Studio-equivalent icons and have renamed/reordered them where appropriate.


As mentioned throughout the blog post, many of the newly released features are in their preliminary phases and we’re actively working to support a broader set of scenarios that are consistent with the Azure ML Studio and SDK experiences. Here are some of the scenarios we’re working on:

  1. Connecting a Notebook in VS Code directly to a compute instance.
  2. Debugging failed experiment runs and pipeline steps using containers and AML environments.
  3. Creating datasets from an existing blob or file-based datastore.
  4. Using AML environments when deploying an endpoint.

If there’s anything that you would like us to prioritize, please feel free to let us know on Github!

If you’re an existing user of the extension and would like to provide feedback, please feel free to do so via our survey.

The post Enhance your Azure Machine Learning experience with the VS Code extension appeared first on Python.

Categories: FLOSS Project Planets

PreviousNext: Testing Twig templates and custom JavaScript with Jest

Planet Drupal - Wed, 2020-07-08 19:11

Jest is the defacto standard for testing in modern JavaScript but we've traditionally not been able to leverage it for testing in Drupal.

But with twig-testing-library, we can now test our twig templates and any dynamic behaviours added by Javascript using Jest.

In this article we will go through the process of adding Jest based testing to an existing accordion component.

by lee.rowlands / 9 July 2020 Installation

Firstly we need to install twig-testing-library and jest

npm i --save-dev twig-testing-library jest

And we're also going to add additional dom-based Jest asserts using jest-dom

npm i --save-dev @testing-library/jest-dom

Now we need to configure Jest by telling it how to find our tests as well as configuring transpiling.

In this project, we've got all of our components in folders in a /packages sub directory.

So we create a jest.config.js file in the root with the following contents:

// For a detailed explanation regarding each configuration property, visit: // https://jestjs.io/docs/en/configuration.html module.exports = { clearMocks: true, // Clear mocks on each test. testMatch: ['/packages/**/src/__tests__/**.test.js'], // How to find our tests. transform: { '^.+\\.js?$': `/jest-preprocess.js`, // Babel transforms. }, setupFilesAfterEnv: [`/setup-test-env.js`], // Additional setup. };

For transpiling we're just using babel-jest and then chaining with our projects presets. The contents of jest-preprocess.js is as follows:

const babelOptions = { presets: ['@babel/preset-env'], }; module.exports = require('babel-jest').createTransformer(babelOptions);

As we're going to also use the Jest dom extension for additional Dom based assertions, our setup-test-environment takes care of that as well as some globals that Drupal JS expects to exist. The contents of our setup-test-env.js file is as follows:

import '@testing-library/jest-dom/extend-expect'; global.Drupal = { behaviors: {}, }; Writing our first test

Now we have the plumbing done, let's create our first test

As per the pattern above, these need to live in a __tests__ folder inside the src folder of our components

So let's create a test for the accordion component, by creating packages/accordion/src/__tests__/accordion.test.js

Let's start with a basic test that the accordion should render and match a snapshot. This will pickup when there are changes in the markup and also verify that the template is valid.

Here's the markup in the twig template

<div class="accordion js-accordion"> {% block button %} <button class="button button--primary accordion__toggle">{{ title | default('Open Me') }}button> {% endblock %} <div class="accordion__content"> {% block content %} <h1>Accordion Contenth1> <p>This content is hidden inside the accordion body until it is disclosed by clicking the accordion toggle.p> {% endblock %} div> div>

So let's render that with twig-testing-library and assert some things in packages/accordion/src/__tests__/accordion.test.js

import { render } from 'twig-testing-library'; describe('Accordion functionality', () => { it('Should render', async () => { expect.assertions(2); const { container } = await render( './packages/accordion/src/accordion.twig', { title: 'Accordion', open: false, }, ); expect(container).toMatchSnapshot(); expect(container.querySelectorAll('.accordion__toggle')).toHaveLength(1); }); }); Running the tests

So let's run our first test by adding a jest command to our package.json under "scripts"

"jest": "jest --runInBand"

Now we run with

npm run jest > jest --runInBand PASS packages/accordion/src/__tests__/accordion.test.js Accordion functionality ✓ Should render (43 ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 1 passed, 1 total Time: 4.62 s, estimated 6 s Ran all test suites. Testing dynamic behaviour

Now we know our template renders, and we're seeing some expected output, let's test that we can expand and collapse our accordion.

Our accordion JS does the following:

  • On click of the accordion title, expands the element by adding accordion--open class and sets the aria-expanded attribute
  • On click again, closes the accordion by removing the class and attribute

So let's write a test for that - by adding this to our existing test:

it('Should expand and collapse', async () => { expect.assertions(4); const { container, getByText } = await render( './packages/accordion/src/accordion.twig', { title: 'Open accordion', }, ); const accordionElement = container.querySelector( '.accordion:not(.processed)', ); const accordion = new Accordion(accordionElement); accordion.init(); const accordionToggle = getByText('Open accordion'); fireEvent.click(accordionToggle); expect(accordionElement).toHaveClass('accordion--open'); expect(accordionToggle).toHaveAttribute('aria-expanded', 'true'); fireEvent.click(accordionToggle); expect(accordionElement).not.toHaveClass('accordion--open'); expect(accordionToggle).toHaveAttribute('aria-expanded', 'false'); });

Now let's run that

npm run jest packages/accordion/src/__tests__/accordion.test.es6.js Accordion functionality ✓ Should render (29 ms) ✓ Should expand and collapse (20 ms) Test Suites: 1 passed, 1 total Tests: 2 passed, 2 total Snapshots: 1 passed, 1 total Time: 5.031 s, estimated 6 s Ran all test suites.

Neat! We now have some test coverage for our accordion component

Next steps

So the neat thing about Jest is, it can collect code-coverage, let's run that

npm run jest -- --coverage packages/accordion/src/__tests__/accordion.test.es6.js Accordion functionality ✓ Should render (28 ms) ✓ Should expand and collapse (13 ms) -------------------|---------|----------|---------|---------|-------------------- File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s -------------------|---------|----------|---------|---------|-------------------- All files | 29.55 | 11.27 | 24.14 | 30 | accordion/src | 100 | 85.71 | 100 | 100 | accordion.es6.js | 100 | 85.71 | 100 | 100 | 53 base/src | 11.43 | 3.13 | 4.35 | 11.65 | utils.es6.js | 11.43 | 3.13 | 4.35 | 11.65 | 14,28,41-48,58-357 -------------------|---------|----------|---------|---------|-------------------- Test Suites: 1 passed, 1 total Tests: 2 passed, 2 total Snapshots: 1 passed, 1 total Time: 2.813 s, estimated 5 s Ran all test suites.

Pretty nice hey?

What's happening behind the scenes

If you've worked on a React project before, you've probably encountered Dom testing library and React testing library. Twig testing library aims to provide the same developer ergonomics as both of these libraries. If you've familiar with either of those, you should find Twig testing library's API's comparable.

Under the hood it's using Twig.js for Twig based rendering in JavaScript and Jest uses jsdom for browser JavaScript APIs.

A longer introduction

I did a session on using this for a Drupal South virtual meetup, here's the recording of it.

Get involved

If you'd like to get involved, come say hi on github.

Tagged Front End Development, Testing, Jest, JavaScript
Categories: FLOSS Project Planets

Lullabot: Alternatives to Upgrading from Drupal 7 to Drupal 9

Planet Drupal - Wed, 2020-07-08 14:07

Drupal 9 was recently released, Drupal 8 will reach end-of-life November 2021, and Drupal 7’s life will expire in November 2022 (the date was extended due to COVID-19). With a window of a little under a year and a half to upgrade from 7 to 9, it's time to make a plan, or pursue other options if that timeline isn't viable. But what other options are there?

Categories: FLOSS Project Planets

Adding EteSync calendars and tasks to Kontact - GSoC 2020 with KDE and EteSync [Part 4]

Planet KDE - Wed, 2020-07-08 14:00


Last month, I wrote about adding EteSync address books to Kontact. Since then, I have been working on extending this functionality to calendars and tasks as well. I am happy to report that fetching and modifying EteSync contacts, calendars and tasks is now possible in Kontact. If you want to test it out, skip to ”Testing the resource” section below. You can read on for updates on the project:

The configuration dialog

When a new EteSync address book or calendar is added to Kontact, a configuration dialog pops up, asking you to enter your EteSync server URL, username, password and existing password. Entering the relevant credentials will fetch your contacts and calendars/tasks in KAddressBook and KOrganizer.

Fetching EteSync contacts, calendar and tasks Adding/Modifying collections and items

Kontact now implements a two-way client for EteSync. Not only does it support fetching data, but we can also use it to create, modify and delete contacts, events and tasks. We can even create new EteSync address books, calendars and task lists right from within Kontact.

Here, all changes made using KOrganiser are reflected in the EteSync web client too.

Creating an event
Deleting an event Testing the resource

Testing the resource is as simple as cloning and building KDE PIM Runtime from this repo.

  • Clone the repo
  • Build the project using make or kdesrc-build
  • Restart Akonadi (akonadictl restart)
  • Open Kontact and add a new EteSync address book or calendar
About the implementation
  • The configuration dialogue is implemented by subclassing the Akonadi::AgentConfigurationBase class.
  • There are basically three handler classes for the three different types - ContactHandler, CalendarHandler and TaskHandler. Classes CalendarHandler and TaskHandler are derived from the abstract class CalendarTaskBaseHandler, which contains a lot of code common for handling calendars and tasks.
What next?
  • The configuration dialog is currently a single dialog that takes as input the username, password, server url and encryption password. It should ideally be a two-step process, where the user enters the server url, username, password and then, on successful login, the encryption password should be entered. This is needed to initialise new accounts which do not have encryption passwords set up.
  • A lot of stuff needs to be looked up and implemented - like setting up the collection refresh rates, the Akonadi cache policies and Akonadi resource status signals.
Categories: FLOSS Project Planets