What makes an EK9 package publishable?
← Package Capability Security · Ref: Q1270
An EK9 package is treated as 'publishable' — and therefore subject to compile-time capability enforcement — only when all FOUR of these are declared in the 'defines package' block:
1. publicAccess (true for the public EK9 repository, false for a private repository) 2. version (consumers need a specific version to reference) 3. license (consumers need to know their legal obligations) 4. capabilities (the list of gated system types the package uses)
All four must be present. A package that has publicAccess + version + license but omits the 'capabilities' block is NOT publishable in the enforcement sense — it compiles as if the feature did not exist, even when it uses gated types. This preserves backward compatibility for packages written before the capability feature landed and gives authors explicit control over when their module enters the enforcement regime.
The 'capabilities' declaration itself is the opt-in signal. Adding it is how an author says 'I am entering the supply chain and accepting the capability-review obligations.'
THE FOUR-CONDITION EXAMPLE
defines package publicAccess <- true version <- 1.0.0-0 description <- "Simple publishable library" license <- "MIT" capabilities <- ["org.ek9.lang::Stdout"]
WHY EXPLICIT OPT-IN
Existing published packages predate the capability feature. Forcing retroactive enforcement would break every existing library the day the feature landed. The fourth-condition rule means each package author decides when their module is ready to declare capabilities, upgrading on their own schedule rather than being blocked by a compiler change.
See Q1271 for how to declare capabilities once your package is publishable. See Q1275 for non-publishable packages. See Q1276 for pure-computation libraries. See Q1277 for error E12010.
Example
defines module qa.packagecapabilities.publishablefourconditions defines package version <- 1.0.0-0 description <- "Demonstrates the four publishable conditions" license <- "MIT" publicAccess <- true capabilities <- ["org.ek9.lang::Stdout"] defines function showCapabilities() stdout <- Stdout() stdout.println("This module is publishable: all four conditions are set.") stdout.println("publicAccess + version + license + capabilities block")
Common mistakes
E12010 — A publishable package declared only TCP as a capability but its code uses Stdout. Each gated type used in the module's non-dev source must be covered by a matching entry in the capabilities list. See ek9 -h E12010 for details.
Incorrect:
capabilities <- ["org.ek9.lang::TCP"]
Correct:
capabilities <- ["org.ek9.lang::Stdout"]
Other ways to ask this
- When does EK9 enforce capability declarations on my package?
- What conditions trigger the publishable package rules in EK9?
- How do I know whether my package is treated as publishable by the compiler?
- I'm preparing to publish a package — what must be in the defines package block?
Coming from another language?
Maven: package metadata is free-form; no declarative capability model. npm: package.json has no permission/capability concept; dependencies run arbitrary postinstall scripts. PyPI: no enforcement — package installs and runs arbitrary code. Cargo: same — no compile-time capability model. Go modules: no capability metadata at all. EK9: four-condition publishable rule activates compile-time capability enforcement per module, with explicit opt-in via the capabilities block.
Keywords: capabilities, package, four conditions, license, supply chain, publicAccess, publishable, version