---
title: "[Update] IPWHL: Maybe the real cheeses are the packages we helped along
the way"
date: 2021-06-21
categories: [blog, project]
tags: [update, ipwhl, python, packaging]
---

So, according to a [recent announcement][ipwhl-annonce] in the mailing list, I
now co-maintain the [IPWHL][ipwhl] project, also known as *Floating Cheeses*
(I prefer the latter for it being more playful and pronounceable, but IPWHL is
just quicker to type). So, I feel obliged to provide a more thorough
introduction.

[ipwhl-annonce]: https://lists.sr.ht/~cnx/ipwhl-announce/%3CCC8HUR1YAFDL.YHJBG1SM70WE%40nix%3E
[ipwhl]: https://sr.ht/~cnx/ipwhl/

## Les Cheeses

In short, IPWHL is a PyPI alternative (though, initially the package database
would be collected from there).  What it provides:

- Decentralization
- Security
- Reproducibility

### Decentralization

IPWHL uses [IPFS][ipfs] for storing packages.  This provides several
advantages:

- No single point of failure
- Easy to mirror
- Faster download thanks to P2P

As there have been several incidents of PyPI outages, this is a strong reason
to use our cheeses.

[ipfs]: https://ipfs.io/

### Security

No single point of failure is a security feature itself, but besides that,
IPWHL also is more secure because:

- We have CIDs and we cryptographically sign the packages thanks to merkle dag
- We avoid packaging packages that are typosquat attacks

### Reproducibility

IPWHL has a pre-resolved dependency and its packaging strategy is similar to
NixOS, a distro known for its reproducibility.  The installer can uses the CID
and the package name to reproduce exactly the package.

## Current problems

Despite the theoretical advantages, IPWHL is a new project and thus has several
problems

### Lack of packages

A distribution doesn't mean anything without packages, and IPWHL is indeed in
need of them.
As of the time I am writing this (2021-06-21), there are less than 100 packages
declared in the database.

Introducing more packages would lead to maintenance problem: we cannot, as two
sole maintainers, keep up with too many packages and make sure they're all
up-to-date.  Therefore, please, come help us if you're interested in this
project.

### Dependency Hell

Maybe you've heard of `npm install is-even` meme, if you hang out in some
programming meme groups.  It represents an underlying problem of having too
many packages depending on each other.  PyPI is saner, I would say, but it does
have that problem.

<figure>
  <picture>
    <source srcset="/images/xkcd-dependency.webp" type="image/webp">
    <img title="Such dependency, wow" alt='xkcd comics "Dependency":
  A tower of blocks is shown. The upper half consists of many tiny blocks
  balanced on top of one another to form smaller towers, labeled:
  "All modern digital infrastructure"
  The blocks rest on larger blocks lower down in the image, finally on a
  single large block. This is balanced on top of a set of blocks on the left,
  and on the right, a single tiny block placed on its side. This one is
  labeled: A project some random person in Nebraska has been thanklessly
  maintaining since 2003' src="/images/xkcd-dependency.png">
  </picture>
  <figcaption>
   <a href="https://xkcd.com/2347">Original XKCD comics</a> shared under a
   CC-BY-NC 2.5 License.<br>  Transcript retrieved (with some edits) from
   <a href="https://explainxkcd.com/wiki/index.php/2347:_Dependency">
   ExplainXKCD</a> shared under a CC-BY-SA 3.0 License.
  </figcaption>
</figure>

I would even say if the package dependency were like the above illustration, it
would be simple.  In reality, *circular dependency* makes it impossible to
declare one package without declaring the other, which can be demonstrated by
this tensegrity shape:

<figure>
  <picture>
    <source srcset="/images/tensegrity.webp" type="image/webp">
    <img alt='a tensegrity structure' src="/images/tensegrity.png">
  </picture>
  <figcaption>
    A tensegrity structure, drawn by me
  </figcaption>
</figure>

Or, in some cases, such as for `tox`, it can even be like this:

<figure>
  <img alt="A tensegrity icosahedron made from straws and string"
  src="https://upload.wikimedia.org/wikipedia/commons/5/5d/Icosahedral_tensegrity_structure.png">
  <figcaption>
  Icosahedral tensegrity structure, retrieved from 
  <a href="https://commons.wikimedia.org/wiki/File:Icosahedral_tensegrity_structure.png">WikiMedia</a>, authored by QuarterNotes,
  shared under a CC-BY-SA 4.0 License.
  </figcaption>
</figure>

## How to help

<picture>
  <source srcset="/images/begging-for-help.webp" type="image/webp">
  <img alt="Rick from *Rick and Morty* dancing and singing 'I'm begging for
help'" src="/images/begging-for-help.png">
</picture>

Due to mentioned problems, it is critical for the project to have contribution.
To start, please take a look at [the manual page][ipwhl-man]

[ipwhl-man]: https://man.sr.ht/~cnx/ipwhl/guides/contrib.md

### Help declaring packages information

Currently, the packages with high priority is listed here:

https://todo.sr.ht/~cnx/ipwhl/5

### Write docs

User and contribution manuals are not really clearly written, and some
information are scattered across the [mailing lists][lists].  You can help by
compile them into a comprehensive structured manual.

[lists]: https://sr.ht/~cnx/ipwhl/lists

### Help resolving dependency conflicts

> *Maybe the real cheeses are the packages we helped along the way*

Some packages cannot be in its latest version, due to some constraints.

A case in point is `Sphinx`, which depends on `docutils` and `docutils-stubs`.
The latest version for `docutils` is 0.17.1, but so far the latest version for
`docutils-stubs` depends on specifically 0.14 versions.  Due to this conflicts,
you can only install `docutils 0.14`.

Therefore, you can help developing and packaging [docutils-stubs][stub] so we
can have newer packages on IPWHL

[stub]: https://github.com/tk0miya/docutils-stubs