biicode’s latest release 2.0 includes the “block tracks” feature.
With block tracks you can have different ‘versions’ of a block using the same block namespace, so you can keep the same #includes in the source code.
When do block tracks come in handy?
- When maintaining different development versions of your source code
- When overriding a dependency in your project
1. Maintaining different development versions of your source code
Last week we uploaded to biicode the powerful libuv library. This library has 3 versions or “tracks”:
- 0.10 (Stable, used by Nodejs)
- 0.11 (Non stable, but commonly used)
- 1.0 (Made stable a few days ago)
There is no right or wrong version of libuv. Well, maybe 0.11 but it’s just been replaced by version 1.0. But 1.0 has only been stable for a few days…
We want the three versions of libuv in biicode so you can choose the one you need or, why not, change or upgrade between libuv versions.
How can I depend on a specific version of libuv?
Edit the [requirements] section of your biicode.conf file and write the track in brackets. E.g.:
Try different libuv “tracks” in your source code just changing this file.
Update to the new libuv 1.0:
How can I publish a new track of my block?
Edit the [parents] section in your biicode.conf file, put the track name between brackets and specify -1 version to create a new block. E.g.:
Note that you don’t need to change your source code’s #includes to change the version of libuv used.
2. Override a dependency in your project
We truly believe that a good dependency manager should allow users to override a dependency on their projects. Regardless of depending on a package directly or indirectly.
How can we do it?
Let’s see an example:
“mike/block” block depends directly on “foo/bar” block version 5, and “foo/bar” has a dependency to “sam/myblock” (version 8). So your block “mike/block” has a dependency to “sam/myblock” (version 8).
What if you (Mike) wanted to depend on “sam/myblock” version 10 instead? Well, that’s easy you can do it with biicode without the block tracks feature.
Just edit [requirements] section of your biicode.conf file and add a line specifying the version you want. Biicode will override “foo/bar” dependency to “sam/myblock” version 10.
But, what happens if you need to change “sam/myblock” to adapt it to your needs or to fix a bug?
Well, a rather ugly/dirty fix is to copy the source code to a new block in your workspace and publish it in your namespace. That way, you can have “mike/block”, but all its #includes should be overriden to “point” to “mike/myblock”.
And if Sam, the original author of “sam/myblock”, repairs the block and releases a new version you will need to change again all the #includes in your source code.
A better solution is to create a track of “sam/myblock”:
- Open “sam/myblock” (bii open sam/myblock)
- Update [parent] section in your biicode.conf file to point to your track: Replace “* sam/myblock:8″ with “* sam/myblock(mike/mytrack):-1″
- Publish your block as usual (bii publish)
In [parent] section you are specifying that the parent block is a track of original “sam/myblock” called “mytrack” in the “mike” namespace. Specifying -1 version means that there is no version published yet, so this command will create the new block.
Tell biicode to use your version of sam/myblock in the [requirements] section of your biicode.conf file:
You may think this looks like a branch or a fork of a block, but this is not it, this is a way to control your dependencies. Branch or Fork are concepts for a control version system and involve merging, diff, pull requests, merge requests… etc. biicode is not a control version system, it’s just a dependency manager. We recommend using git and use Github or Bitbucket to manage your version control.
In the next days I will write another blog post about how I have uploaded libuv library to biicode and showing you how to work with Git and block tracks in a real project.
I hope you enjoy this post and, as always, we look forward to read what you think. Just click on the sidebar button to try biicode, check our docs, forum and/or Stackoverflow tag for questions and answers.