Is it normal or acceptable for packages to be removed from PyPI?
5 votes c/freepost Posted by zPlus — 5 votes, 10 commentsSource

I’m building documentation for dokk, which entails downloading and building some old packages. To my surprise, some dependencies don’t seem to be available anymore from pypi. In particular there’s one called codecov that’s given me the most problems. Developers lock the dependency to some version, like 2.0 or 2.1.12, but on pypi there’s only the latest release. Older ones are nowhere to be found.

It is one of the biggest problems of centralized repos. Users worship it but…

To be honest I don’t know if a more decentralized repository would solve this problem. I feel like someone hosting a package on a tiny server is more likely to dismiss it than a centralized repository, where the package can be uploaded and forgotten forever. The solution as always should be backup backup backup.

OK. The main problem is another. The problem that it is designed to be one end point. I am not about technology maybe supports several endpoints and etc but I am about how people use it and tend to think. We have one worshiped repo. The end. People don’t usually think that they can have several end points. At most I usually see custom caching proxy it even usually not repo clone (partial with necessary packages only). Rust is about Cargo cult but it allows you to add any package repository you want. And I am sure that pythons pip also can it but it is hidden in the sense it isn’t mainstream to talk about opportunity to add another repo… Rust’s Cargo even allow you to connect git repository as “repo” so you have dependency “somelib”? Soooo you can just do if it is on mainstream repo:

somelib = "<version>"

And accidentally bomb destroy all the servers of so official repo is dead… You just can write:

somelib = { version = "<version>", registry = "my-registry" }

with just adding one new registry in settings (Yeah I am sure python also can it but it isn’t mainstream to talk about it…)

or maybe you can just use git repo of the library

somelib = { git = "" }

And you can specify concrete branch or tag or commit by just adding one more parameter…

And as I know you can specify registry and git at the same time as fallback…

It is flexible, as like I am sure pythons pip but when you start to learn about dependencies you will immediately know at least about opportunity to use git bareback as source of your dependency and rust docs encourage you to know about different registries, dependency overwriting and etc.

What python does? Ehhh… Python users are usually taught by people that say. Just import some lib. Sometimes even without explanation of repo existence.... Just use and don’t worry.... And you don’t need to understand. (╥﹏╥)

What if repo will <insert something about bad service>? – Just use it!!! You don’t need to know anything else!! It is your god now.

P.S After this message you could think I hate python and it is users… No. It isn’t so I just hate PyPI cult and the fact the python don’t try to teach people to be independent from PyPI like rust’s cargo do…

Don’t Rust developers use like Python developers use Looks like the same problem to me.

In general yes many of rust developers are like PyPI cultists but rust docs encourage you to know about different registry options and heavily encourage you to use git. In the sense that it is normal to open someones repo and find there git link or open library docs that encourage you to use git (mostly for nightly features).

I am not user of PyPI but cargo ecosystem feels more failure-tolerant and knowledge friendly. I didn’t saw (maybe overlooked) in PyPI community any forces to spread knowledge and ideas of redistribution so I decided not to enter…


Is there a release page anywhere? I tend to avoid PyPI, npm… because security issues. You can use the ‘git submodule’ command or update manually to keep them up-to-date.

I can only find “tags” releases in their github page, but not binary releases. Luckily this problem doesn’t happen often. I ended up updating it manually, and luckily the new version didn’t break the build.

It is difficult to avoid these technologies in our world. Especially when you need to build someones else project. I prefer to use local repos or as you said git submodule but I totally love rust’s ability to use git repo as dependency by just writing:

somelib = { git = "" }

Python package-managers can also accept repositories as dependencies, but the de facto behavior is that of downloading from pypi or whatever repository the package manager is using. I think it’s all about using pre-built binaries.

Rust don’t have prebuild packages…

Many repos like Maven don’t provide you opportunity to download source code and build everything yourself. I understand that prebuilt binaries are good but if you can’t build it by yourself you can’t trust it. Yeah Trusting trust article ;) but…