Ansible Galaxy 'Lock' file support

[geerlingguy]

It would be helpful if Ansible Galaxy supported a 'lock' file.

When running ansible-galaxy install -r requirements.yml, Ansible Galaxy could create a requirements.lock file (or some other name) that stores the following metadata for each downloaded role:

• Role name
• Role version or branch identifier used
• Specific git tag or hash downloaded

Then, if running the command ansible-galaxy install -r requirements.yml again, it would install based on the exact identifiers in the lock file.

The details could be a little different, of course, and we'd need a command like ansible-galaxy update -r requirements.yml to update an existing lockfile... but this would make idempotent playbook configurations much easier for many projects without requiring all downloaded roles be stored in the project repository (e.g. like Drupal VM currently does.

Other examples of lock file support:

• Python pipfile
• Node.js yarn.lock file
• PHP composer.lock file
• Ruby Gemfile

Original Request

For Drupal VM, we've decided to pin our requirements.yml file's role requirements to specific versions (e.g. 3.0.1, 2.5.0, etc.).

It would be nice if we could support some method of semver with role versions (instead of just requiring a branch or tag... and maybe this is related to/duplicate of #70), where you could specify a dependency in requirements.yml like:

- src: geerlingguy.apache
  version: 1.7.*

When galaxy picks the tag to pull, it would check for any in the 1.7.x range, and choose the latest release. That way I don't have to spend so much time maintaining all my requirements files for various projects.

I would love to see something as involved as Composer's Version support, but I know that's a bit of a moonshot. It would be nice to have a lock file that would set the versions currently installed, too, as that would even allow me to set master but lock in the versions at a specific point in time.

Anyways, I was just thinking about how awesome it is to point at tagged role releases in terms of keeping one's playbook completely idempotent and stable—yet how annoying it is to have to manually tinker with the requirements.yml file so often.

[gregdek]

Just set up #168 for tracking this, take a look.

[gregdek]

Reopening because this is actually different from just versioning.

[geerlingguy]

See also: https://github.com/pypa/pipfile

[jackbentley]

~~~Shouldn't some simple matching to check that the specified version in the `requirements.yml` is met, else download a version which does meet it, be a sufficient stop-gap for anything more intelligent? It won't downloaded the latest version, but ensures there's always a compatible version.~~~

*Edit: Is but isn't really related to the problem in question. my bad, didn't quite fully understand the question at first*

[geerlingguy]

Yarn (Node.js) also has a lock file system similar to PHP's Composer: https://yarnpkg.com/en/docs/yarn-lock

[geerlingguy]

See also: https://www.kennethreitz.org/essays/announcing-pipenv

[tknerr]

Similar in Ruby, where bundler is the dependency manager of choice:

• the Gemfile lists the dependencies w/ version constraints (equivalent to requirements.yml)
• upon resolving the dependencies a Gemfile.lock is being created, which tracks the exact versions which have been resolved (e.g. the SHA for git based dependencies)
• not only for the explicitly specified dependencies, but also for all their transitive dependencies

As a result, if you keep the Gemfile.lock (e.g. you may want to commit this for release versions) you can repeatably resolve the exact same dependency tree, i.e. you get reliable and idempotent installation of depedencies if you will.

See also:
https://stackoverflow.com/questions/7517524/understanding-the-gemfile-lock-file
https://stackoverflow.com/questions/6927442/what-is-the-difference-between-gemfile-and-gemfile-lock-in-ruby-on-rails

[tknerr]

but I think fuzzy matching and lockfile support are two different issues.

the last comments were only concerned about lockfile support

@geerlingguy is fuzzy matching still a concern for you? should we split it up in two different issues?

Probably also somthing for https://github.com/ansible/proposals

[geerlingguy]

Yeah, let's drop fuzzy matching from this issue—that will require a bit more work and is probably much lower priority (I know it is for me... a lock file would be AWESOME and help me immediately in so many ways, and is not blocked on versioning discussions, semver etc.).