Essentially, a software package repository sounds like a dream: with a simple command, you can access countless software, libraries, etc., making it easy to use the operating system or develop software. However, the other side that is fairly obvious is that someone must maintain all these packages, and those who use the repository must trust that whatever their package manager gets from the repository is what they want.
How to manage the ownership of packages in such a repository depends on the specific software repository. In particular, the famous JavaScript repository NPM often suffers from public relations disasters because it is loose and fast in terms of package ownership.Recently, after Andrew Sampson broke in, NPM’s automatic ownership transfer function was quietly withdrawn and deleted It painfully backfired.
In short, who can judge when a package is truly “abandoned”, to ensure that a package is free of malware, and how to start providing insurance for the package being pulled and lost? Half of the internet crashes With it?
NPM as a case study
In Andrew Sampson’s Twitter topic, He described how in the process of obtaining packages for a project named Bobo Published in various software repositories, he found that the name was unclaimed except in NPM.Since this package has not been updated for a long time, he speculated that it was probably abandoned and found one Package name dispute entry In the NPM documentation. Due to what happened next, this entry has been severely changed.
Following the steps in the NPM document, Andrew emailed the existing author Bobo Package and CC’ing NPM support as required. Four weeks later, he received an email from NPM support, letting him know that he now has the NPM package:
Everything looks good and fancy, until it turns out not only Bobo It is still being actively developed by Zach Kelling, but at least 30 different packages on NPM depend on it. In the subsequent exchange, Zach and Andrew realized that npm owner ls The command has nothing to do with the package, which explains why Zach never received any news about the transfer of ownership.
There are many obvious failures here: from NPM’s failure to determine that it has an active communication channel with the package owner, to no clear way to determine whether a packet is really abandoned, to NPM apparently not proceeding before discarding a packet Basic dependency checking. pack. Perhaps the most shocking thing here is NPM’s “solution”. Zach did not restore ownership of the package, but only a GitHub Pro subscription and a $100 coupon can be purchased from the GitHub store. Andrew finally compensated Zach for the package name.
In his thoughts on the entire experience, Andrew made it clear that he did not believe that the software repository should have the right to change the ownership of the package, and this responsibility should always be borne by the owner. That is, in terms of practicality, people may argue that if a package has not been downloaded for a long time and no other software depends on it, it can be considered abandoned.
But is NPM really an outlier? How does their strategy compare to the maintainer-centric model used by other repositories (such as those provided by various Linux and BSD distributions)?
The burden of convenience
One feature of the NPM software repository is its high degree of accessibility. In a sense, anyone can Create an account and publish There are almost no prerequisites for their own software packages. This is in stark contrast to the Debian software repository.The process here is that in order to add the package to the Debian archive, you Must be a Debian developer, Or ask someone to sponsor you and upload your package on your behalf.
Although it is still possible to create packages for Debian and distribute them without these prerequisites, this means that users of your software must manually download the DEB file and install it, or add the URL of the archive server to the configuration file to add them The package manager is used as a personal package archive (PPA) to install and update packages as well as packages from the official Debian archive.
The basic principle behind the Debian software repositories and software repositories of other distributions is that by essentially being Chain of trust. By ensuring that everyone who contributes something (such as a package) to the repository is a trusted party of at least one person in the contributor chain, you can almost ensure that all contributions are legal. Barring a security breach, users of these official repositories know that software installed through any available software package is what their developers want.
This is in stark contrast to specialized software repositories for specific programming languages. PyPI as the official Python software repository has Similar prerequisites As an NPM, because you only need a user account to start publishing. Other languages, such as Rust (Crates.io) And Java/Kotlin (Sonatype Maven) Follow similar policies. This is the same as Tex (CTAN) And Perl (CPAN), which seems to provide a certain degree of verification for project developers. By the way, CPAN’s policy when changing package maintainers is that this can only be done after a lot of effort and time. Even so, it’s better to add a co-maintainer instead of deleting or changing the package content.
Most of these differences seem to use the motto “Move fast and break things“Although abandoning the chain of trust can make the project progress at a very fast speed, it may come at a price. Finding the right balance here is the most important. For example, in the case of an operating system, this kind of impact on quality and safety The careless approach to reliability and reliability is obviously very undesirable.
One might assume that “breaking things” is also very undesirable when deploying a new project into production and failing due to dependencies or worse. However, this is where opinions seem to differ so much that one can say that the standard package manager for a given programming language (if any) directly reflects the type of developer interested in developing that language, and vice versa.
Do you really need that?
Anyone who frequently tries to build a Node.js project a few months ago or a Java 6 project based on Maven may prove that dependencies can be easily broken. a lot of. Whether it is the entire package disappeared, or just an old version of the package, over time, the possibility of building a project without spending at least a few minutes to curse and edit the project files will gradually become zero.
Given what these dependencies sometimes bring, they are simply dependencies that may be more ridiculous. E.g, left-pad The packages in NPM that caused many projects to fail include Only a few lines of code This is exactly what it says on the tin. It does raise the question of how many project dependencies can be discarded without significantly affecting development time, while potentially saving a lot of catastrophic downtime and simplifying maintenance.
When your file browser hangs for a few seconds or more while parsing the file node_modules The directory of the Node.js project, because of how many folders and files there are, this may indicate a problem.Some people have already started to take measures to reduce this bloat, such as This article is by Adam Pollack Who described reducing the size node_modules Project folders from 700 MB to 104 MB. This is achieved by finding alternatives to large dependencies (often introducing many of your own dependencies), removing unnecessary dependencies, and using custom code instead of certain dependencies.
Another good reason to reduce dependencies has to do with startup time, because Stefan Baumgartner points out In a recent blog post.Although typing is obviously annoying npm install And have enough time to have lunch before the end, he mentioned Works by Mikhail Shirkov Compare cold start time with cloud-based service offerings. Increasing the total size of deployed applications will also significantly increase the cold start time, in seconds. These are billed by the second, which is actually a waste of money. Large applications waste tens of seconds when starting and sorting out dependencies, which is actually useless.
The additional time required is also reflected in areas such as continuous integration (CI) and deployment (CD), and developers have noticed an increase in the time required to build Docker images. Obviously, minimizing the dependencies and their size in the project can have a very real-time time and money impact.
Kiss instead of spoiling things
There is a lot to say to keep it as simple as possible in a software project. Although it is undoubtedly attractive to launch a dump truck with dependencies and complete the work quickly, this approach should ideally be reserved for rapid prototyping and proof of concept, rather than production-level code.
Through my own experience in (commercial) NPM-based JavaScript projects and Maven and Gradle-based Java projects using various Nexus repository servers, I began to appreciate the simplicity and stability of less is more. Adding dependencies to the project is something that should be considered in depth, and it is best to avoid dependencies or eliminate the need for included items. If you add, you should consider whether this dependency is external or exists in the source tree.
After all, making the project bulletproof is something that deserves more appreciation.This includes reducing reliance on code and infrastructure provided by others, especially if said code and/or infrastructure is provided Free of charge. If your business plan Including continuing to provide For certain free services and software, any sane investor should think twice before investing.