Meta tags:
description=A program for developing Haskell projects. ;
author=Stack contributors;

Headings (most frequently used words):

files, lock, stack, snapshot, procedure, yaml, and, recursive, layers, performance, file, contents, creation, update, config, build, command,

Text of the page (most frequently used words):
stack (54), the (51), file (35), lock (29), yaml (26), files (24), #snapshot (22), and (19), build (17), information (16), that (15), this (14), for (13), project (11), configuration (11), package (8), all (8), completed (8), are (8), snapshots (8), not (7), packages (7), contents (7), procedure (6), lts (6), sha256 (6), like (6), can (6), ghc (6), from (5), config (5), locations (5), get (5), hackage (5), layers (5), extra (5), deps (5), level (4), other (4), cabal (4), command (4), new (4), update (4), will (4), same (4), example (4), size (4), acme (4), missiles (4), topics (4), more (4), performance (4), these (4), recursive (4), incomplete (4), version (4), how (4), getting (4), options (4), commands (4), with (3), contributors (3), see (3), any (3), default (3), disk (3), there (3), location (3), you (3), creation (3), https (3), url (3), they (3), given (3), works (3), instead (3), fully (3), changes (3), refers (3), which (3), users (3), key (3), used (3), source (3), flags (3), involved (3), integration (3), building (3), configure (3), started (3), when (2), description (2), whenever (2), loaded (2), those (2), using (2), subject (2), option (2), out (2), writing (2), missing (2), loading (2), created (2), document (2), assume (2), run (2), path (2), original (2), raw (2), githubusercontent (2), com (2), commercialhaskell (2), stackage (2), master (2), 729011 (2), 3c412a7c13dba6d3d808455a458e0776c58b6cf99b8a7961a2f5e55589d6f1d6 (2), 226 (2), 614bc0cca76937507ea0a5ccc17a504c997ce458d7f2f9e43b15a10c8eaeb033 (2), pantry (2), tree (2), 2ba66a092a32593880a87fb00f3213762d7bca65a687d45965778deb8694c5d1 (2), 613 (2), haskellstack (2), org (2), looks (2), following (2), mutable (2), note (2), also (2), parsing (2), common (2), remote (2), available (2), haskell (2), never (2), change (2), future (2), could (2), hash (2), deterministic (2), world (2), revisions (2), machines (2), plans (2), standard (2), provide (2), include (2), work (2), table (2), glossary (2), faq (2), upgrading (2), maintainers (2), code (2), non (2), docker (2), script (2), environment (2), specific (2), projects (2), setting (2), welcome (2), github (2), made, material, mkdocs, copyright, 2015, 2025, back, top, loads, above, without, taking, steps, than, generating, applicable, hpack, format, even, collected, form, memory, compared, against, one, differences, written, completing, does, exist, then, use, rest, simply, dry, checks, extension, added, starting, lowest, layer, listed, order, encountered, docs, stable, lock_files, please, documentation, should, edit, hand, was, autogenerated, only, applies, included, immutable, contains, addition, acting, pure, correctness, mechanism, design, here, improvement, requiring, parsed, each, invocation, store, bypass, additional, case, need, encode, ensure, detect, anything, where, via, http, mysnapshotb, mysnapshota, particularly, feel, therefore, while, general, nothing, prohibits, happening, complete, may, specify, enough, resolve, some, consider, parent, relevant, discussion, specifies, explains, updated, tarball, remotely, deleted, possible, perform, however, mean, either, performs, fails, accidentally, doing, something, different, rerunning, plan, depending, state, reuse, identical, local, stored, control, address, follow, fairly, approach, having, goal, cache, themselves, many, operations, rely, upon, transitively, includes, dependencies, expensive, calculate, entering, reproducibility, tedious, would, things, hashes, tarballs, etc, want, enter, attempts, reproducible, involves, reproducibly, exact, set, input, few, problems, making, history, resources, overview, signing, self, hosted, runners, zip, msys2, add, maintainer, team, process, releases, scheme, dev, containers, contributor, guide, azure, travis, shell, auto, completion, developing, windows, visual, studio, editor, debugging, initialization, nix, interpreter, specification, directories, root, customisation, scripts, global, directive, variables, upload, upgrade, unpack, uninstall, test, templates, setup, sdist, runhaskell, runghc, repl, query, purge, list, install, init, ide, hpc, hoogle, haddock, ghci, exec, eval, dot, clean, bench, conclusion, interactively, executing, multi, targets, synonyms, installed, databases, existing, your, hello, initializing, search, skip, content,

Text of the page (random words):
lock files stack skip to content stack lock files initializing search github welcome setting up getting started commands configure topics get involved faq glossary more stack github welcome setting up getting started getting started 1 a hello world example 2 package description 3 project configuration 4 building your project 5 building existing projects 6 installed package databases 7 stack build synonyms 8 stack build targets 9 multi package projects 10 cabal flags and ghc options 11 locations used by stack 12 executing commands 13 using ghc interactively 14 stack configuration 15 in conclusion commands commands bench build clean config dot docker eval exec ghc ghci haddock hoogle hpc ide init install list ls new path purge query repl run runghc runhaskell script sdist setup templates test uninstall unpack update upgrade upload configure configure environment variables configuration files configuration files project specific configuration non project specific configuration the include directive global flags and options customisation scripts topics topics stack root stack work directories stack environment snapshot location package location snapshot specification stack yaml vs a cabal file script interpreter docker integration nix integration non standard project initialization building ghc from source debugging editor integration stack and visual studio code developing on windows shell auto completion ci travis ci azure ci lock files lock files table of contents stack yaml and snapshot files recursive snapshot layers performance lock file contents creation procedure update procedure stack config build files command haskell and c code get involved get involved contributors contributors contributor s guide dev containers maintainers maintainers version scheme releases maintainer team process add ghc version upgrading msys2 upgrading 7 zip haskellstack org self hosted runners signing key how stack works how stack works build overview faq glossary more more other resources version history table of contents stack yaml and snapshot files recursive snapshot layers performance lock file contents creation procedure update procedure stack config build files command lock files stack attempts to provide reproducible build plans this involves reproducibly getting the exact same contents of source packages and configuration options like cabal flags and ghc options for a given set of input files there are a few problems with making this work entering all of the information to fully provide reproducibility is tedious this would include things like hackage revisions hashes of remote tarballs etc users do not want to enter this information many operations in stack rely upon a snapshot hash which transitively includes the completed information for all of these dependencies if any of that information is missing when parsing the stack yaml file or snapshot files it could be expensive for stack to calculate it to address this we follow the fairly standard approach of having a lock file the goal of the lock file is to cache completed locations of project snapshot packages and snapshots themselves so that these files can be stored in source control users on other machines can reuse these lock files and get identical build plans given that the used project packages and local snapshots are the same on those machines rerunning stack build in the future is deterministic in the build plan not depending on mutable state in the world like hackage revisions note if for example a tarball available remotely is deleted or the hash changes it will not be possible for stack to perform the build however by deterministic we mean it either performs the same build or fails never accidentally doing something different this document explains the contents of a lock file how they are used and how they are created and updated stack yaml and snapshot files relevant to this discussion stack s project level configuration file stack yaml by default specifies the parent snapshot the snapshot key extra deps some of this information can be incomplete consider this stack yaml file snapshot lts 24 43 extra deps acme missiles 0 3 this information is incomplete for example the extra deps may change in the future instead you could specify enough information in the stack yaml file to fully resolve that package that looks like extra deps hackage acme missiles 0 3 sha256 2ba66a092a32593880a87fb00f3213762d7bca65a687d45965778deb8694c5d1 613 pantry tree size 226 sha256 614bc0cca76937507ea0a5ccc17a504c997ce458d7f2f9e43b15a10c8eaeb033 the lts 24 43 information is also incomplete while we assume in general that haskell lts snapshots never change there is nothing that prohibits that from happening instead the complete version of that key is snapshots url https raw githubusercontent com commercialhaskell stackage snapshots master lts 24 43 yaml size 729011 sha256 3c412a7c13dba6d3d808455a458e0776c58b6cf99b8a7961a2f5e55589d6f1d6 users do not particularly feel like writing all of that therefore it is common to see incomplete information in a stack yaml file recursive snapshot layers snapshot files can be recursive where stack yaml refers to mysnapshota yaml which refers to mysnapshotb yaml which refers to a remote snapshot file available via an http s url we need to encode information from all of these snapshot layers and the stack yaml file in the lock file to ensure that we can detect if anything changes performance in addition to acting as a pure correctness mechanism the design of a lock file given here also works as a performance improvement instead of requiring that all snapshot files be fully parsed on each stack invocation we can store information in the lock file and bypass parsing of the additional files in the common case of no changes lock file contents the lock file contains the following information completed package locations for extra deps and packages in snapshot files note this only applies to immutable packages mutable packages are not included in the lock file completed information for the snapshot locations it looks like the following this file was autogenerated by stack you should not edit this file by hand for more information please see the documentation at https docs haskellstack org en stable topics lock_files packages listed in the order that they are encountered in the layers of snapshots starting at the lowest layer completed hackage acme missiles 0 3 sha256 2ba66a092a32593880a87fb00f3213762d7bca65a687d45965778deb8694c5d1 613 pantry tree sha256 614bc0cca76937507ea0a5ccc17a504c997ce458d7f2f9e43b15a10c8eaeb033 size 226 original hackage acme missiles 0 3 snapshots completed sha256 3c412a7c13dba6d3d808455a458e0776c58b6cf99b8a7961a2f5e55589d6f1d6 size 729011 url https raw githubusercontent com commercialhaskell stackage snapshots master lts 24 43 yaml original lts 24 43 creation procedure whenever a project level configuration file stack yaml by default is loaded stack checks for a lock file in the same file path with a lock extension added for example if you command stack stack yaml my stack yaml build or stack stack yaml my stack yaml build dry run then stack will use a lock file in the location my stack yaml lock for the rest of this document we will assume that the files are simply stack yaml and stack yaml lock if the lock file does not exist subject to stack s lock file option it will be created by loading the stack yaml loading all snapshot files completing all missing information writing out the new stack yaml lock file to the disk update procedure whenever a project level configuration file stack yaml by default is loaded all completed package or snapshot locations even those completed using information from a lock file get collected to form a new lock file in memory subject to stack s lock file option that new lock file is compared against the one on disk and if there are any differences written out to the disk stack config build files command the stack config build files loads a project level configuration file see above without taking any other build steps other than generating when applicable a cabal file from a package description in the hpack format back to top copyright c 2015 2025 stack contributors made with material for mkdocs