<commit_before>The paket.lock file
====================

Consider the following [paket.dependencies](Dependencies_file.html) file:

    source "http://nuget.org/api/v2"

    nuget "Castle.Windsor-log4net" "~> 3.2"
    nuget "Rx-Main" "~> 2.0"

Here we specify dependencies on the default NuGet feed's `Castle.Windsor-log4net` and `Rx-Main` packages; both these packages have dependencies on further NuGet packages. 

The `paket.lock` file records the concrete resolutions of all direct *and indirect* dependencies of your project:-

    [lang=textfile]
    NUGET
      remote: http://nuget.org/api/v2
      specs:
        Castle.Core (3.3.0)
        Castle.Core-log4net (3.3.0)
          Castle.Core (>= 3.3.0)
          log4net (1.2.10)
        Castle.LoggingFacility (3.3.0)
          Castle.Core (>= 3.3.0)
          Castle.Windsor (>= 3.3.0)
        Castle.Windsor (3.3.0)
          Castle.Core (>= 3.3.0)
        Castle.Windsor-log4net (3.3.0)
          Castle.Core-log4net (>= 3.3.0)
          Castle.LoggingFacility (>= 3.3.0)
        Rx-Core (2.2.5)
          Rx-Interfaces (>= 2.2.5)
        Rx-Interfaces (2.2.5)
        Rx-Linq (2.2.5)
          Rx-Interfaces (>= 2.2.5)
          Rx-Core (>= 2.2.5)
        Rx-Main (2.2.5)
          Rx-Interfaces (>= 2.2.5)
          Rx-Core (>= 2.2.5)
          Rx-Linq (>= 2.2.5)
          Rx-PlatformServices (>= 2.2.5)
        Rx-PlatformServices (2.3)
          Rx-Interfaces (>= 2.2)
          Rx-Core (>= 2.2)
        log4net (1.2.10)

If the `paket.lock` file is not present when [paket install](paket_install.htm) is requested, it will be generated. Subsequent runs of [paket install](paket_install.htm) will not reanalyze the `paket.dependencies` file or touch `paket.lock`.

All changes after the initial generation will be as a result of [`paket install`](paket_install.htm) or [paket update](paket_update.htm) commands.

As a result, committing the `paket.lock` file to your version control system guarantees that other developers and/or build servers will always end up with a reliable and consistent set of packages regardless of where or when a [paket install](paket_install.htm) occurs.<commit_msg>fix links<commit_after>The paket.lock file
====================

Consider the following [paket.dependencies](Dependencies_file.html) file:

    source "http://nuget.org/api/v2"

    nuget "Castle.Windsor-log4net" "~> 3.2"
    nuget "Rx-Main" "~> 2.0"

Here we specify dependencies on the default NuGet feed's `Castle.Windsor-log4net` and `Rx-Main` packages; both these packages have dependencies on further NuGet packages. 

The `paket.lock` file records the concrete resolutions of all direct *and indirect* dependencies of your project:-

    [lang=textfile]
    NUGET
      remote: http://nuget.org/api/v2
      specs:
        Castle.Core (3.3.0)
        Castle.Core-log4net (3.3.0)
          Castle.Core (>= 3.3.0)
          log4net (1.2.10)
        Castle.LoggingFacility (3.3.0)
          Castle.Core (>= 3.3.0)
          Castle.Windsor (>= 3.3.0)
        Castle.Windsor (3.3.0)
          Castle.Core (>= 3.3.0)
        Castle.Windsor-log4net (3.3.0)
          Castle.Core-log4net (>= 3.3.0)
          Castle.LoggingFacility (>= 3.3.0)
        Rx-Core (2.2.5)
          Rx-Interfaces (>= 2.2.5)
        Rx-Interfaces (2.2.5)
        Rx-Linq (2.2.5)
          Rx-Interfaces (>= 2.2.5)
          Rx-Core (>= 2.2.5)
        Rx-Main (2.2.5)
          Rx-Interfaces (>= 2.2.5)
          Rx-Core (>= 2.2.5)
          Rx-Linq (>= 2.2.5)
          Rx-PlatformServices (>= 2.2.5)
        Rx-PlatformServices (2.3)
          Rx-Interfaces (>= 2.2)
          Rx-Core (>= 2.2)
        log4net (1.2.10)

If the `paket.lock` file is not present when [paket install](paket_install.html) is requested, it will be generated. Subsequent runs of [paket install](paket_install.html) will not reanalyze the `paket.dependencies` file or touch `paket.lock`.

All changes after the initial generation will be as a result of [`paket install`](paket_install.html) or [paket update](paket_update.html) commands.

As a result, committing the `paket.lock` file to your version control system guarantees that other developers and/or build servers will always end up with a reliable and consistent set of packages regardless of where or when a [paket install](paket_install.html) occurs.
{'fraction_non_alphanumeric': 0.13555401341660883, 'fraction_numerical': 0.04302567661346287, 'mean_word_length': 2.4536741214057507, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 37, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5737677', 'n_tokens_mistral': 1598, 'n_tokens_neox': 1506, 'n_words': 402}