DEV Community: chris48s

Identifying Abandoned PyPI Packages

chris48s — Fri, 23 Aug 2024 20:10:45 +0000

Relying on abandoned and deprecated packages in our applications is generally something we want to avoid. pip-abandoned can help with this. In some packaging ecosystems, the registry allows you to mark a package as deprecated or abandoned. For example in NPM:

and Packagist:

This also allows package managers to consume this metadata to provide a warning at install time:

PyPI doesn't have this concept. The registry does not provide any way to abandon or deprecate a package, and this makes it harder to tell if you are relying on a package which is no longer maintained. However, there are some signals we can look at. The best of which is: If a package on PyPI is linked to a GitHub repository and that GitHub repository is archived, this is a strong signal that the package itself is no longer maintained.

pip-abandoned takes into account several signals and allows us to search a virtual environment or requirements.txt file to identify suspected abandoned or deprecated packages.

If abandoned packages are found, pip-abandoned will produce a summary:

The tool exits with code 0 when no abandoned packages were found and a non-zero code when one or more abandoned packages were found. This means you can use it as a CI check as well as for ad-hoc audits.

Failing the CI build if django migrations are out of date

chris48s — Wed, 12 May 2021 19:13:10 +0000

A common mistake in django is to make a model change but forget to run makemigrations to generate a migration for the model change. Sometimes it is not entirely obvious when this need to happen. For example, let's say I'm using the django-extensions library and I define a model like:

# models.py

from django.db import models
from django_extensions.db.models import TimeStampedModel

class MyModel(TimeStampedModel, models.Model):
    pass

In this situation, upgrading django-extensions to a new version might require me to regenerate the migrations in my app, even though I haven't made any changes to models.py and overlooking this could generate unexpected results.

Fortunately there is a simple thing I can do to detect and warn if this happens: If I run

python manage.py makemigrations --check

in my CI build, this will cause the build to fail if my migrations are out of sync with the models, warning me about the problem.

Three useful pathlib snippets

chris48s — Thu, 06 May 2021 16:19:19 +0000

from pathlib import Path
p = Path('/foo/bar')


# Read in a text file
text = (p / 'file.txt').read_text()

# Recursively list all .csv files in directory
csvs = list(p.rglob('*.csv'))

# Iterate files or subdirectories
files = [i for i in p.iterdir() if i.is_file()]
subdirs = [i for i in p.iterdir() if i.is_dir()]

Pathlib Cheat Sheet

chris48s — Thu, 06 May 2021 16:18:16 +0000

>>> from pathlib import Path
>>> f = Path.home() / 'foo.tar.gz'
# same as f = Path('/home/chris/foo.tar.gz')

>>> f.is_file()
True

>>> f.is_dir()
False

>>> f.exists()
True

>>> f.absolute()
PosixPath('/home/chris/foo.tar.gz')

>>> f.as_uri()
'file:///home/chris/foo.tar.gz'

>>> f.as_posix()
'/home/chris/foo.tar.gz'

>>> f.parts
('/', 'home', 'chris', 'foo.tar.gz')

>>> f.suffix
'.gz'

>>> f.suffixes
['.tar', '.gz']

>>> f.parent
PosixPath('/home/chris')

Editing Commit Timestamps in Git

chris48s — Mon, 03 May 2021 18:44:39 +0000

I always forget that GitHub shows commits in a pull request in timestamp order rather than tree/history order until just after I've just pushed a monster rebase and everything's in the wrong order. To force GitHub to show the commits in the correct order, we need to edit the commit timestamps to match the history order. To do this:

git rebase -i HEAD~N

Mark the commits that need re-ordering as edit

edit f3b9e40 Reticulate Splines
edit 68f39b8 Adjust Bell Curves
edit d605e5a Dice Models

At each stage of the rebase:

git commit --amend --date=now --no-edit
git rebase --continue

Now the timestamp ordering will match the history. When you force-push, GitHub will order the commits correctly in your pull request.