Galaxy does not support branch names as version in requirements file about ansible HOT 10 CLOSED

@sivel Hola, I believe this issue was intended to be created in the core repo. I don't have permission to transfer the issue to https://github.com/ansible/ansible though. Could you please take a look and do the transfer or advise on where else it should go? Cheers!

from ansible.

Files identified in the description:

None

If these files are incorrect, please update the component name section of the description or use the component bot command.

from ansible.

@svartoyg: Greetings! Thanks for taking the time to open this Issue. In order for the community to handle your Issue effectively, we need a bit more information.

Here are the items we could not find in your description:

• Summary
• Component Name
• Issue Type

Please set the description of this Issue with an appropriate template from:
https://github.com/ansible/ansible/tree/devel/.github/ISSUE_TEMPLATE
or
https://raw.githubusercontent.com/ansible/ansible/devel/.github/PULL_REQUEST_TEMPLATE.md

click here for bot help

from ansible.

@sivel Hola, I believe this issue was intended to be created in the core repo. I don't have permission to transfer the issue to https://github.com/ansible/ansible though. Could you please take a look and do the transfer or advise on where else it should go? Cheers!

Sorry for posting the issue at the wrong spot. I don't know how to move it, but i could create a copy in the proper spot.

from ansible.

We've already moved the issue, but it is lacking information that we generally request. See the comment at #83288 (comment) for providing more info

from ansible.

You can fix immediately for all versions by changing the format to this:

collections:
- type: git
  name: https://gitlab.some.doamain/foo/bar.git
  version: test

This is a duplicate of #81687 and #78067. During the dep resolver rewrite the original implementation #69154 grew legs, such as being more lenient with requirement.yml formatting. Before #72591, a collection source is a Galaxy server, not the collection itself (it would be ignored for type: git, and you'd get an error that the name foo.bar couldn't be cloned, unless the path foo.bar exists as a git repo). It's not in the changelog and I think it was unintended, so the behavior should be restored if possible (ideally, give a warning/error for unintended option combinations).

These combinations should be pointless

• source, version with a collection in a tarfile or directory (there is no Galaxy server involved, and version is determined by the artifact)
• source with a collection in a git repo (same reasoning) - version is allowed, but as a committish (for example, a semver version is wrong unless there's a tag or branch by that name) and has no bearing on the version which is installed which needs to be semver and is determined by the repo content at the committish.

Other than the committish caveat, version and source are only useful for type: galaxy, to determine from which server and which release to install for a name following the foo.bar pattern.

I think this is a documentation issue also, see #75872 (welp, I helped propagate that pattern...). Much better would have been to use name instead of source. I think I glossed over it at the time because I figured if it 'worked', okay then (I was personally against the feature and not opinionated in how people would use it), and didn't consider that people would swap type: dir for type: git and expect that to also work, which was never intended.

from ansible.

That does the trick, indeed.

I guess adjusting the documentation for now would be a good thing. On the long run, i guess it would be better to revise the whole syntax for the requirements file, since some keys seem quite unintuitive (e.g. name for the repository url).

Thank you, s-hertel!

from ansible.

I agree that as a whole it's not intuitive. It evolved over time and all new formats have been additive (I think just having one format would help with this problem). You can write it without using name too:

collections:
  # same syntax as used to install roles from a git repo, also the syntax to install without a requirements file
  - git+https://gitlab.some.doamain/foo/bar.git,test

  # could still use this for collections on a server
  - name: amazon.aws
    source: http://localhost:5000/api

from ansible.

These combinations should be pointless

• source, version with a collection in a tarfile or directory (there is no Galaxy server involved, and version is determined by the artifact)
• source with a collection in a git repo (same reasoning) - version is allowed, but as a committish (for example, a semver version is wrong unless there's a tag or branch by that name) and has no bearing on the version which is installed which needs to be semver and is determined by the repo content at the committish.

Other than the committish caveat, version and source are only useful for type: galaxy, to determine from which server and which release to install for a name following the foo.bar pattern.

Might misunderstand, but what do you mean with version and source is only useful for type: galaxy?

The following works great:

---
collections:
  - name: ansible.posix
    version: 1.5.4
    source: https://github.com/ansible-collections/ansible.posix.git
    type: git
  - name: community.crypto
    version: 2.20.0
    source: https://github.com/ansible-collections/community.crypto.git
    type: git
  - name: community.general
    version: 9.0.0
    source: https://github.com/ansible-collections/community.general.git
    type: git

https://github.com/konstruktoid/ansible-role-hardening/blob/master/requirements.yml

from ansible.

Might misunderstand, but what do you mean with version and source is only useful for type: galaxy?

@konstruktoid That's the 'committish' behavior I described in the section quoted. See, they're tags https://github.com/ansible-collections/ansible.posix/releases/tag/1.5.4.

version in the requirements file is not necessarily the installed version of the collection for the types: file, url, dir, or subdirs. The version is determined by the galaxy.yml/MANIFEST.json file in the collection itself. type: git is a wrapper around type: dir (or optionally type: subdirs, which is a wrapper around type: dir(s)).

The version: HEAD could refer to all the versions at some point, or the same version even though the plugins are not the same, etc, how branches/tags and the galaxy.yml/MANIFEST.json are managed is completely up to the git repo.

The awesome thing about type: galaxy is that version can be a range, making useful dependency resolution happen for you when there are dependencies by the same name, and compatible upgrades can be installed without knowing which upgrades are available.

I would somewhat caution against type: git (and type: subdirs and type: dir as these are all basically the same thing under the hood) for the non-developer scenario because it's less obfuscation to install a tarfile or git clone/cp -r directly when possible (if trying to avoid using a galaxy server, which is really missing out on the best ansible-galaxy features imo). I pushed for the feature to install from git repos because I thought testing a PR against ansible, which was once a couple steps (checkout, test) might become a few for collections in some scenarios (checkout, build, install, test) and while it was initially rejected, it ended up getting accepted as a tool for collection development (same number of steps: build + install shortcut in one, test). It isn't a great replacement for installing from a server or tarfile, which is the well-trodden path, and there are a lot of things I want improved about the feature as it stands now (I often put together POCs, like devel...s-hertel:ansible:compare-type-dir-content), but the general feedback I get related to this feature is trepidation/disinterest so it has gone nowhere for a while. If you are interested, any feedback is helpful so it's not only my opinion. I would be happy to receive any related suggestions or discuss more in IRC or https://forum.ansible.com any time.

(@svartoyg sorry for the repeated tangents I've gone on to try to give context about how the feature got to this point, that are not super relevant to your very valid points about the UX)

from ansible.