Package Managers, the whats, whys and hows
16 July 2020 by Dawid Wozny
Introduction
I have been waiting for a package manager like GPM for a long time and it is finally here. We have tried multiple options for reusing code and all of them had some drawback which caused us to stop using them. It was either the license cost, difficult to use or integrate into our process or just that it didn't do what we wanted it to.
Why use GPM?
For an overview of what a package manager is, check out this Wikipedia page, which is a great introduction. I would like to summarise all the options we have tried in a separate post so let’s focus on GPM now. For me the biggest advantages of GPM is that your reusable/packaged code travels along with your project source code. Is it a big deal? For me it is. Here is why:
- When you share code with a customer, your college or come back to a project after a few years there is no need to install any package manager, even GPM, your code/dependencies are already there. If you prefer you can only have one person in your team who manages GPM packages, others would only pull the code from the repo.
- If you find a bug in reusable code you can fix it, commit the code and have confidence that your changes will always be there. Don’t get me wrong, I don’t claim thie is good practice but if you need to do it, it is good to know it will work in all the environments. Let’s consider a scenario that you have discovered a bug in somebody’s reusable code (I had a situation like this in the past with the code distributed on JKI Package Manager). The only way to fix it properly, is to ask maintainer to do or if the repository is public to do it yourself and then send pull request to that person. Either way it will take significant time for you to get the update. Most of the people who are creating packages do it for free, this is absolutely fantastic but it also means they will not fix it immediately, they will do it on their own schedule. So what did I do? I fixed it on my computer and was happy until I had to come back to it after two years using another computer. The code didn't work anymore because my fix was applied only on one machine. This wouldn’t happen with GPM. I would apply the fix in my repo and commit. If the fix was available from the maintainer (either after my pull request or them coding it) I would update the package, test it, and depending on the results commit or revert the change. Everything strictly controlled and in suitable time.
- If you have an urgent need to change the code slightly, you can do it. This is the same case as with bug fix, I don’t claim it to be good practice but you can do it if you really need to and even when you come back to your project everything is there. If this is your reusable code, once you have a backward compatible version with your other projects then you can update the package. If somebody else maintains the code you could do extra work and send a pull request. If that’s not the case and the license allows for it you could create a fork and start maintaining another version of the code. The last option is to leave the code as you committed and this will also work provided you don’t need the change in your other projects.
Besides the fact packaged code travels in our repository, GPM has other advantages:
- Packages can reuse code from another package. This is not a big deal when using most package managers, but when we tried using git submodules for code reuse it was a bit tricky.
- It is open and completely free. You can support it if you want.
- There is already a big chunk of reusable code provided by MGI and Composed Systems. It is far from JKI PM but it is pretty early days of this package manager.
Optimised usuage
Although I have mentioned that you can bug fix packaged code in your repo I hardly ever do it with my code. Most of the time I do it the right way. What it is the right way? Fix the package, release it, update package in your project code. If I were to do it manually it would probably be too much effort for me, happily we have got Continuous Integration (CI) to do it for us. It is enough for me to commit the change in the package source repository, then wait for CI to validate the change, release the package and update it in the project.
How to use it?
Let’s discuss how GPM operates. It comes with two versions Command Line Interface (CLI) (handy for CI) and GUI. I will focus on GUI as it is more intuitive when using it for the first time.
Here are a few steps you need to do to get GPM up and running:
- Install and start GPM
- The first thing you will see is a prompt for selecting a folder, select the folder for the project where you want to use the packages.
- You will see the following screen. GPM automatically treats your project as the package and gets its name from the folder. Select minimal version of LabVIEW and press OK.
- The next screen you see is GPM browser listing all the installed packages in your project. There is nothing there just yet as we have just started.
- When you browse to the project folder you will see gpackage.json file. This is the place where all the metadata related to dependencies is stored. It is almost empty just a few parameters.
- Let’s install a package we want to reuse. I will go to the ‘Browse’ tab, type @mgi and press search.
- This will list all the available public packages published by MGI. Then I will select @mgi/json, on the right panel you will see the information about the package including change log and license. Hit Install Dev Package(s).
- Once the install is complete I see the following screen:
- Now I can go to my project folder where I see gpm_packages folder, inside there is another @mgi and finally json where the code sits in.
- gpackage.json has also changed and now lists @mgi/json as dependency
- When we go to the top level project we will see packaged code in GPM_Packages virtual folder ready to use
- That’s it, you can commit all the code and start using it. Having all the packages in source version control will allow you to track if any changes were made to this code accidentally and if they were deliberate to find them and potentially apply them in the original package source code.
Back to Blog listings