During this call, we will discuss, Managing Dependencies in Ballerina:
- Packaging system in Ballerina
- Built-in dependency manager
- Automatic version udpates
- Version compatibility ranges
- Producing predictable builds
- Working with unpublished packages
Sign up for future community calls here: https://bit.ly/3i9Wi5O
2. Ballerina
● An open-source programming language for the cloud that
makes it easier to use, combine, and create network services
● Batteries included: libraries, package manager/dependency
manager, build system, test system, documentation system,
IDE support
● Should be easy for programmers familiar with C-style
languages
3. Managing dependencies in Ballerina
● bal: a build system and package manager for Ballerina
● Working with Ballerina packages
● Automatic version updates
● Compatible version ranges
4. bal
● A multipurpose tool used for:
○ building Ballerina programs
■ bal build, bal run, bal test commands
○ package management
■ bal new/bal init, bal build, bal pull, bal push commands
○ managing Ballerina platform updates
■ bal dist pull, bal dist use, bal dist update commands
5. Ballerina package manager
● Provides a mechanism to organize, version, build and share Ballerina
source code
● Fetches correct versions of all dependencies (direct and transitive) of
a Ballerina program
● Keeps the dependencies up to date
● Provides a way to achieve repeatable builds
6. Ballerina source file (.bal)
→ cat hello_world.bal
import ballerina/io;
public function main() {
io:println("Hello, World!");
}
→ bal run hello_world.bal
Compiling source
hello_world.bal
Running executable
Hello, World!
→ bal build hello_world.bal
Compiling source
hello_world.bal
Generating executable
hello_world.jar
→ bal run hello_world.jar
Hello, World!
7. Ballerina module
● A Ballerina program is a combination of modules
● Composed of one or more .bal files
● A namespace that isolate module-level identifiers from other modules
to achieves encapsulation, modularity and code reuse
● The external view of a module is made up of public identifiers
defines in the source files
● May depend of other modules
9. Ballerina package
● Allows one or more modules to be combined, versioned, and
distributed as a single entity
● Two formats: source and distribution
● Source format stores the package’s content in a hierarchical
filesystem
● Distribution format stores the content in an archive file with .bala
extension
12. Package repository
● Stores packages by organizing them into a three-level hierarchy:
○ organization,
○ package name,
○ version
● organization is a way of grouping packages that belong to single
person, team or organization
● Package names can be hierarchical: ballerinax/aws.s3
● Package versions follow SemVer
● Ballerina central is the default package repository
13. Where should I specify package versions?
● Hold that thought!
15. Automatic version updates
● Build command automatically pull and use new versions of
package dependencies
○ Does not happen for every build.
○ Every 24 hours in Swan Lake Beta3
● Notifies the user by updating the Dependencies.toml file
● A necessary evil required to keep dependencies up to date
● Makes builds non-deterministic
● Sensible version range locks to minimize the impact
16. Locking modes
● Soft lock
○ Locks to major versions of dependencies
● Medium lock
○ Locks to major versions of dependencies
○ Locks to minor versions (if possible) of dependencies
● Hard lock
○ Locks to exact major.minor.patch versions of dependencies
17. Default locking mode
● The build command uses the medium locking mode as the default
● For every dependency, update to the latest patch version
● When different dependencies require different minor versions of
another dependency, take the least minor version needed to satisfy
the all requirements
○ Package A requires 1.2.3 version of package C
○ Package B requires 1.4.3 version of package C
○ The latest versions of C in Ballerina central are 1.5.1 and 2.1.0
○ Medium locking mode picks 1.4.3
18. Compatible version ranges
● Follows SemVer compatibility ranges when comparing versions
● Similar to the compatible ranges defined in Rust
● Versions are considered compatible if their left-most non-zero
major/minor/patch component is the same
○ 1.2.3 and 1.5.0 are compatible, but 1.2.3 and 2.0.0 are not compatible
○ 0.8.0 and 0.8.10 are compatible, but 0.8.00 and 0.9.0 are not compatible
○ 0.0.1 and 0.0.2 are not compatible
● Pre-release versions of the same major.minor.patch version are
compatible
○ 1.2.0-alpha and 1.2.0-beta are compatible
19. Sticky builds
● Automatic version updating is a handy tool, but it can be turned off
● Useful in situations that requires repeatable builds
○ i.e. uses the exact dependencies used in a previous build
○ Dependencies.toml captures dependencies resolved during the previous
compilation
● The bal build --sticky option attempts to stick to the
dependency versions available in the dependencies.toml
○ If the files doesn’t exist, this option is ignored
20. offline builds
● The bal build --offline option attempts to proceed without
accessing the network
● Attempts to use the previously downloaded dependencies, fail
otherwise
● Downloaded dependencies are stored in local repository caches