flk import

Import an environment declaration written for another tool into an flk profile. Today the only supported source is Devbox’s devbox.json.

If the directory has no flake.nix yet, flk import runs flk init for you first, so a Devbox project can be converted in a single command.

`flk import devbox`

flk import devbox                      # import ./devbox.json into the default profile
flk import devbox --dry-run            # show the translation, write nothing
flk import devbox --file ../devbox.json
flk import devbox --profile backend    # import into a specific profile

What gets translated

`devbox.json`	flk equivalent
`packages`	the profile’s `packages` list
`packages` with `@version`	`packages` + a pin in `.flk/pins.nix`
`env`	the profile’s `envVars`
`shell.scripts`	the profile’s `commands` (see flk cmd)
`shell.init_hook`	appended to the profile’s `shellHook`

Both shapes of packages are accepted — the list form and the object form:

{ "packages": ["ripgrep", "go@1.22"] }
{ "packages": { "go": { "version": "1.22" } } }

shell.init_hook and each script may be a string or a list of strings; both are handled.

A version of latest is treated as unpinned, since that is already flk’s default behaviour for a package with no --version.

A package written as name@version goes through exactly the same path as flk add --version: the pin is resolved against nixpkgs and recorded in .flk/pins.nix, and the profile declares pkgs."name@version". This means an import of a manifest with many pinned packages performs several network round-trips per package — use --dry-run first if you want to see the plan before waiting.

What does not get translated

These are reported under a Not imported heading at the end of the run rather than being silently dropped:

include — Devbox plugins have no flk equivalent and must be translated by hand.
env_from — dotenv sourcing. Add the variables with flk env add.
per-package platforms / excluded_platforms — the package is imported for all systems.
unrecognized keys — anything a newer Devbox release added that flk does not know about.

Devbox template variables such as {{ .DevboxDir }} in env values are copied verbatim and flagged with a warning; they will not expand and need editing.

Behaviour on conflicts and failures

A package already declared in the profile is replaced, matching flk add.
An environment variable or command the profile already declares is skipped with a warning, so an import never silently overwrites something you wrote.
An entry that cannot be imported (for example, a package name that does not resolve in nixpkgs) does not abort the run. Every other entry is still imported, the failures are listed at the end, and the command exits non-zero.

Options

Flag	Description
`-f, --file <PATH>`	Manifest to read (defaults to `./devbox.json`)
`-p, --profile <NAME>`	Target profile (defaults to the project default)
`--dry-run`	Print the translation and exit without writing

Example

$ cat devbox.json
{
  "packages": ["ripgrep", "go@1.22"],
  "env": { "GOFLAGS": "-mod=vendor" },
  "shell": {
    "init_hook": ["echo 'entering the shell'"],
    "scripts": { "build": ["go build ./..."] }
  }
}

$ flk import devbox
$ flk show
$ flk activate

Flk Documentation