How to design a package manager


  • A package manager has to cater for many different needs: the needs of the module developer, the needs of the app developer, and the needs of the runtime. These are not conflicting needs, they're just different needs that need to be addressed. Module devs want to write modules, and consider packaging and releasing them a chore, so they need a package manager that stays out of their way. App devs want to write apps, so they need a fast route to a running system so they can start coding right away. Having to build packages and having to put them together into a dev environment takes a way a lot of that initial enthusiasm if the ride is bumpy. Finally, the runtime needs to be able to find all the modules and dependencies regardless of platform, current directory, etc., and do so automatically without burdening the developer with minutia about how it's all glued together, and if possible, without incurring additional runtime costs.

    There's also the reality of the app developer becoming a module developer. This happens all the time, in fact it happens every time you feel like a module that you developed for your app alone might be useful for other projects as well, and/or you would like to share it with others. Extracting a module from an app and giving it a life of its own turns you into a module developer. It's reasonable to expect that you should design a nice API for it, that you should write a modicum of documentation on it, and that you should push it into a remote repository if you want to share it, and ideally that would be the end of it.

    With most package managers however, that's just the beginning of the effort that you have to put in. Now you have write a manifest file, package it, and now and in the future only use the package manager to deploy it back into your dev environment. All this work to get you right back were you started. Except it's worse than were you started, because now you can no longer work on that module from its initial place in your dev tree and push back changes to your repository, because the module was now deployed by the package manager and your git work tree is somewhere else (facepalm).

    Luapower was specifically designed to reduce and in many cases eliminate all these little frictions that make people avoid using package managers.

    Next time I'll write about how each aspect of luapower is handled by different components and how they fulfill the needs we just mentioned.

    Here's a shortlist:

    • git: version management, integrity management, secure transport, authentication
    • github: storage, code sharing platform
    • multigit: package management ui
    • luapower-repos: package list
    • bundle: for making single-exe app deployments
    • luapower: dependency tracking, extracting and aggregating package metadata
    • directory layout conventions: what makes all components work together in harmony

    In the mean time check out https://luapower.com/philosophy


  • 1
    Posts
    525
    Views
    Log in to reply

Internal error.

Oops! Looks like something went wrong!