[Update] IPWHL: Maybe the real cheeses are the packages we helped along the way
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.
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 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.
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.
Transcript retrieved (with some edits) from ExplainXKCD shared under a CC-BY-SA 3.0 License.
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:
How to help
Due to mentioned problems, it is critical for the project to have contribution. To start, please take a look at the manual page
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. You can help by compile them into a comprehensive structured manual.
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 so we can have newer packages on IPWHL