So, according to a recent announcement in the mailing list, I now co-maintain the 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.
In short, IPWHL is a PyPI alternative (though, initially the package database would be collected from there). What it provides:
IPWHL uses 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.
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
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.
Despite the theoretical advantages, IPWHL is a new project and thus has several problems
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.
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.
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:
Or, in some cases, such as for
tox, it can even be like this:
Due to mentioned problems, it is critical for the project to have contribution. To start, please take a look at the manual page
Currently, the packages with high priority is listed here:
User and contribution manuals are not really clearly written, and some information are scattered across the mailing lists. You can help by compile them into a comprehensive structured manual.
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
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
Therefore, you can help developing and packaging docutils-stubs so we can have newer packages on IPWHL