Problems faced when downstream testing Python packages

Downstream testing refers to the testing of software package done by their redistributors, such as Linux distributions. It could be done by distro-specific CI systems, package maintainers or — as it frequently is the case with Gentoo — even distribution users.

What makes downstream testing really useful is that it serves a different purpose than upstream testing does. To put it shortly, upstream testing aims to ensure that the current code of the package works in one or more reference environments, and meets quality standards set by the package authors. On the other hand, downstream testing aims to ensure that a particular version of the package (possibly an old one) works in the environment that it will be used on, or one that closely resembles it.

To put it another way, downstream testing may differ from upstreaming testing by:

  • testing a different (possibly old) package version
  • using a diferent (possibly newer) Python version
  • testing against different dependency versions
  • testing against an environment with additional packages installed (that may interfere unexpectedly)
  • testing on a different operating system, architecture, hardware, setup

While these may sound inconvenient and sometimes cause false positives, they have proven in the past to detect issues that went unnoticed by upstream and that could have broken production setups. Downstream testing is important.

Unfortunately, many test suites make assumptions that cause problems for downstream testers. Some of them can be worked around easily, others can not. In this article I’d like to discuss a number of these issues.

Continue reading

X-alpha hexadecimal notation

The most common way to represent hexadecimal (or any other base > 10) numbers is to use the first letters of alphabet for the extra digits. However, this doesn’t work well for my brain that insists that since A is the first letter, B is the second letter… then A = 10 + 1, B = 10 + 2… so I keep having to remember to shift this by one, and judging by the responses to my toot about it, it seems that I’m not alone.

I don’t think that I’ve made any useless invention that people would randomly find and say “oh, hey, what a nice unrealistic idea”. It’s time to make one! I present to you: the X-alpha hexadecimal notation!
Continue reading “X-alpha hexadecimal notation”

Naming standards compliance of PEP517 backends

PyPA maintains two standards regarding packaging artifact filenames:

I have decided to give a few popular PEP 517 backends a go and see whether they follow the standards.

Continue reading “Naming standards compliance of PEP517 backends”

The inconsistencies around Python package naming and the new policy

For a long time, the dev-python category in Gentoo did not follow any specific naming policy. Usually we went for what made the ebuild easier — the GitHub project name, if we happened to be using GitHub archives as distfiles, or PyPI project name when using source distributions from PyPI. However, this was inconvenient for users who had a hard time finding specific packages. Historically, we even had cases of developers independently adding a second copy of the same package with different name.

This is why I eventually started researching the standards for Python package naming, and drafting a new policy. The package name policy can now be found in the Gentoo Python Guide. In this post, I’d like to summarize the research that led to forming it, and the problems that we are to face yet.

Continue reading “The inconsistencies around Python package naming and the new policy”