Solving the Dependency Management Problems in V

Since the V programming language (or simply V) started open its doors to the public last June, a lot of the work has been done in order to attract more users to use the language. Recently, V has gained the ability to install and use third-party modules from a central repository and things have been shaky since it started. More notably, VPM, the language's primary module/package registry has been hijacked by the "Zig shenanigans". This lead to more and more problems not just the registry but also the feature itself. While the language itself is in alpha stage and far from being safe-to-use in the production environment, things like this must be tackled and solved in it's early stages.

I have been an avid user of the language since day one and it really pushed the boundaries between an easy-to-use language and a fast low-level (C-like) language. Last July I have started what would be my first ever project written on V which is a package manager. At first, it was meant to be a toy project just to explore the capabilities of an alpha-stage compiler. But after I posted the project on Reddit, many (only 13+ people upvoted it but still considerably many given the size of the community at that time) have taken this into notice. Slowly I realized that this project would also have greater effect into the community so that's where I made this project a "serious" one.

Enter VPKG

Introducing vpkg: the alternative package manager for V. It's features were derived from other package managers like NPM, Nimble, and go get. It has lockfile and manifest generation, installs modules either to the "./vmodules" (before that it was "vlib/") directory or locally to your project folder. To be fair, it was never meant to influence the design for V.

VPKG strives to be decentralized, resilient, and interoperable. It supports multiple module/package manifests (v.mod and it's very own .vpkg.json) as well as fetching packages from multiple package registries (for now, vpm and vpkg-registry are built-in into VPKG). So you can be assured that if one of the registries are down, the other one will handle the package for you.

Lockfile generation

One of the great things NPM and Yarn had is the ability to track down dependency conflicts through it's lockfile mechanism. I implemented a similar feature of it to VPKG and now you can be able to update your third-party modules through it. VPKG's stores the information into .vpkg-lock.json file and it looks like this:

{
    "version": "0.3",
    "packages": [
        {
            "name": "package-1",
            "version": "0.0.1"
        }
    ]
}

The 'version' stated here is the last version of VPKG which was used on and the rest is just a list of packages which was installed into the project. For now, modules installed directly from the git repository are being tracked through their last commit hash. Pretty nifty.

Manifest file

In other programming languages, package manifest serves as a useful data for identifying the package and it's dependencies. VPKG uses it's own .vpkg.json file for storing module/package metadata. Again inspired from NPM, .vpkg.json leverages JSON as a standard for data and has following fields which maybe useful for anything (for example, dependency analysis).

V too has its own package metadata which is v.mod that is directly inspired from the go.mod of GoLang. While VPKG also supports v.mod, we also encourage to make use of our manifest file as it also supports git URL's, VPM module identifiers, and normal package names when you list them as your dependencies so you can install of them directly by just simply vpkg install to your project.

Registry

Amidst of the ever-growing pains and problems found in the VPM registry, I have launched my own too. The VPKG registry is a "mirror" registry for those who want to submit their third-party modules. The best part of it is that it is straightforward: fork the registry, submit a PR, and once it has been approved it can be added to it in just minutes. It also utilizes GitHub's infrastructure too so you can be assured that it is always available whenever where ever.

The future

There are a lot of things that will be added in order to make dependency management a lot more better and easier for newcomers. In the near feature, VPKG will support for multiple custom registries for true decentralization as well as support for publishing modules into your favorite registries. Focusing also into features that VPM will implement will be the top priority too to ensure interoperability and avoid fragmentation in the language ecosystem.

Does it solve the problem?

For me, it does help in solving the problem V has right now but it also creates a second confusion for newcomers as to what they should be using when it comes to managing their projects. The V community all in all might think this would not make sense anymore after all as this feature have been released in the recent 0.1.18 version. But I honestly think that these things might help thrive the ever-growing ecosystem of the language. And the one way of philosophy of V might sound great to you, when it comes to the tooling part, this philosophy might not work at all. Finding solutions will ever be part of the evolution of the language which continues to be better in every release.

Contribute to VPKG

The VPKG project is a side-project I created and maintained whenever I have free time and contributions are always welcome! In fact, I am in dire need in making the program test-able by CI and also making it simpler for contributors to contribute code to the repository. To learn more, you can simply visit the VPKG org repo here. By contributing a single line of code or feature, you also help make it better for developers to maintain projects written on V.