Allow for multiple pinned versions of a collection to be installed

alikins commented 5 years ago

Feature Request

For a use case where a project or playbook has a requirements.yml that is specifying versions for roles or collections, if more than one specific version of a collection is installed, mazer will fail.

To support this case, mazer will need some way to allow multiple versions of a collection to be installed at the same time (although, not necessarily in the same content path, but that will be up to implementation).

One of the current design assumptions/requirements for mazer/content path is that there is no support for multiple versions of a content to be installed at the same time. This may need to change.

In combination with the design assumption/requirement that there is only one content path, this means there is no way for mazer to install more than one specific version of a role or collection. This conflicts with some common workflows, including the one suggested by geerlingguy in his ‘how to write a playbook’ talk.

In particular, the suggestions for using a requirements.yml to specify the versions of roles needed for a playbook. If the requirements.yml is used by mazer to install to the default content paths, this will fail attempting to install multiple versions of the same content.

Use Case

What problem does this feature solve? Please describe. A clear and concise description of what the problem is. Ex. I have an issue when [...]

The use case is based on the recommended workflow at https://www.ansible.com/blog/make-your-ansible-playbooks-flexible-maintainable-and-scalable

Proposed Solution

Describe the solution you'd like

There are a couple potential highlevel approaches.

1. Don't support multiple side-by-side versions at all.
  
  Simplest to implement, but seems like a growing problem. This would need docs/best practices on the best ways to handle similar use as the talk linked above addresses.
1. Allow multiple content paths (places a set of collections live on disk) to be used, with predictable precedence and name resolution.
  
  This would be similar to the behavior of $PATH environment variables or other ansible paths that support an ordered list of locations ('ROLES_PATH' for ex).
  
  In this approach, each collection path would only include one version of a collection, but since there are multiple collection paths, more 'local' and specific locations could override default locations.
  
  To cover the use cases described above, this may require adding support for CWD or playbook relative collection paths to allow the most specific overrides.
1. Allow multiple side by side versions of content to be installed in a single collections path
  - con: update gets lot more complicated
  - con: list/info get slightly more complicated
  - pro: supports best practice recomended workflow ala geerlingguy
  - pro: it is kind of unavoidable
  - needs a mechanism to avoid install path collisions
    1. Add a collection version element into the path of the collection
      - ie, ~/.ansible/content/geerlingguy/php/6.3.1/roles/php/
    - non pinned versions use version like 'default' or 'latest' or 'main' whatever
      - ie, ~/.ansible/content/geerlingguy/php/latest/roles/php
    - non-latest version only used if specified (via requirements.yml for example)
    - con: one deeper path for the installed collection
    - pro: all php versions installs share a common parent dir
    - pro: '/' already restricted char
      1. Add version info to installed name of collection
    - For ex, use collection_name@version like
      - ie, ~/.ansible/content/geerlingguy/php@6.3.1/roles/php
    - non-pinned version no '@'
      - ie, ~/.ansible/content/geerlingguy/php/roles/php
    - pro: similar to how some other tools handle it (rvm? maven?)
    - con: requires string parse of collection name
    - '@' is already a reserved char afaik, but this would use it
  - For 1,2 plugin/role loader would both need to learn how to handle that case
  - updates would mostly just ignore pinned versions
  - but that may depend on the 'requirement' they were installed for
    - ie, if foo@1.2.3 was installed because something required 'foo = 1.2.*' then it's unclear when it should be updated
    - would have to track info about why it was installed and update would have to take it into account.
    - introduces complications if a collection version was installed that satisfied multiple requirements. ie, a requirement for 'foo = 1.2.3' and 'foo = 1.2.*'.

Alternatives

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Implementation

Teachability, Documentation, Adoption, Migration Strategy If you can, explain the user story, and possibly provide a version of the docs. Maybe a screenshot or mockup of the design?

alikins commented 5 years ago

See also discussions on https://github.com/ansible/proposals/issues/7

alikins commented 5 years ago

And to summarize/tl;dr the first post...

There are (at least) three related problems to solve:

Having a way to have multiple versions of a role or collection 'installed' that doesn't conflict on disk
Having a mechanism to select which of the available installed versions are in use at any given time.
The rules and conventions for updating and managing content with multiple versions. Since multiple versions implies that at least one is not the 'latest', there needs to be a way to express how the pinned versions are managed. Historically, in other pkg mgr like tools, this part gets very complicated very quickly.

ansible / mazer