"I also don’t particularly propose rewriting what I’ve done so far given that it’s backwards compatible"
This would be fine with me. "I would prefer not to support a mixed format roles file - how about if the filename ends ‘.yml’ or ‘.yaml’ we treat it as yaml, otherwise use the existing format." +1 This could be applied on top. On Sun, Aug 17, 2014 at 3:21 AM, Will Thames <[email protected]> wrote: > My implementation only uses three fields, in an order that is backward > compatible with the existing roles file, and I’m not sure what the other > proposed fields would be. > > However, I like the YAML idea if only because it would work much more > nicely with the dependencies section of meta/main.yml too. > > I would prefer not to support a mixed format roles file - how about if the > filename ends ‘.yml’ or ‘.yaml’ we treat it as yaml, otherwise use the > existing format. > > I also don’t particularly propose rewriting what I’ve done so far given > that it’s backwards compatible - any change would be to support the yaml > notation in addition (which would also be extensible to any of the other > proposed fields I’ve forgotten about). > > Will > > On 17 Aug 2014, at 00:52, Michael DeHaan <[email protected]> wrote: > > Positional fields could be a problem, we already have a proposal for like > 5 of them, and in different cases it's now seaming like they are in > different orders. I think we need to reset here. If we're proliferating > on fields, here is what I propose. > > * (A) continue to support the existing syntax for the galaxy-username, > version > > * (B) use a list of YAML hashes for the approved syntax, and update the > documentation > > * (C) go down the YAML path if the first non-space character is a "-" > > Perhaps it looks roughly like this: > > ---- > > - repo: git+ssh:// > role_name: blippy > version: ... > > - galaxy: username.rolename > recursive: false > > - galaxy: username.rolename2 > version: 1.2.3 > > - galaxy: username.rolename_is_terrible > role_name: save_as_this > > ?? > > > > > > > > > > > > On Fri, Aug 15, 2014 at 8:07 AM, Will Thames <[email protected]> wrote: > >> Ok, friendly role names now allowed as third field. >> >> Added bonus of installing roles from URLs without SCM (think nexus, >> artefactory or just e.g. direct bitbucket/github/stash download URLs) >> >> Integration tests and unit tests to demonstrate that these improvements >> seem to work as expected. >> >> Will >> >> >> On Friday, August 15, 2014 10:22:44 AM UTC+10, Will Thames wrote: >> >>> Perhaps we could make role name an optional third field - so if you do >>> want role_name but not role_version, just leave role_version blank i.e. git+ >>> http://git.server/bad-role-name,,nice-role-name >>> >>> The reason for making it the third field is that I don't want to break >>> existing roles files and I don't want the parsing for SCM roles to be >>> fundamentally different to the galaxy roles. >>> >>> I don't particularly wish this to block the take-up of this pull >>> request, but I'm happy enough to implement it if the above seems a >>> reasonable approach. >>> >>> Will >>> >>> On Friday, August 15, 2014 3:03:36 AM UTC+10, Ivaylo Bratoev wrote: >>> >>>> I can think a few cases where being able to control local role folder >>>> names would make things cleaner. For example: referencing repos with the >>>> same name in the end, too long or obscure repo names, etc. >>>> None of this is a blocker that would stop us from using this feature. I >>>> am looking forward to having this in the main branch and in a official >>>> release. >>>> >>>> On Thursday, August 14, 2014 3:10:29 PM UTC+3, Michael DeHaan wrote: >>>> >>>>> " would just add one more requirement - being able to overwrite the >>>>> role-name and rely on the git repo name exclusively. Idea for syntax if >>>>> you >>>>> want to keep the *role_name/url, role_version* format:" >>>>> >>>>> While interesting, we don't want to do this because we already have >>>>> ",version" used for describing roles in a way that is not specific. >>>>> Further, I don't think those URLs technically support comments in the >>>>> case >>>>> of ssh://, so that seems like something we'd want to avoid. >>>>> >>>>> We can go with git+https://url,version >>>>> >>>>> I'm happy with that. >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Aug 14, 2014 at 12:17 AM, Ivaylo Bratoev <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I am currently investigating different options for managing roles and >>>>>> looking forward to having this in Ansible itself. My requirements are >>>>>> similar - having roles shared (and versioned) in private git repos, >>>>>> referenced from playbooks in other repos. >>>>>> The solution you are discussing here sounds like in the right >>>>>> direction. I would just add one more requirement - being able to >>>>>> overwrite >>>>>> the role-name and rely on the git repo name exclusively. Idea for syntax >>>>>> if >>>>>> you want to keep the *role_name/url, role_version* format: >>>>>> git+https://git.acme.com/ansible/role-logstash.git#alias=logstash >>>>>> >>>>>> This would reference the role from the private repo but use the name >>>>>> 'logstash' instead of 'role-logstash'. >>>>>> >>>>>> If you are OK to change the format to *role_name, scm, url *the >>>>>> syntax suggested by Sam would work well for us: >>>>>> logstash,git,https://git.acme.com/ansible/role-logstash.git >>>>>> >>>>>> Ivo >>>>>> >>>>>> >>>>>> On Thursday, August 14, 2014 3:37:03 AM UTC+3, Will Thames wrote: >>>>>> >>>>>>> I'm happy enough with this approach but how do we apply that to role >>>>>>> dependencies. >>>>>>> >>>>>>> In my git test role I provide a git dependency: >>>>>>> https://bitbucket.org/willthames/git-ansible-galaxy/src/1e58 >>>>>>> ef87f234926caaf5e6b1f2c5378d90f476b1/meta/main.yml?at=master >>>>>>> >>>>>>> This works with the ansible-galaxy in the pull request but would not >>>>>>> as it stands without some form of scm detection. >>>>>>> >>>>>>> On reflection, I think I'd be happiest with the scm+url suggestion - >>>>>>> this would eliminate the need for scm detection and keep the >>>>>>> role_name/url, >>>>>>> role_version format of the rolesfile >>>>>>> role_name would continue to be derived from the repo name. >>>>>>> >>>>>>> From Sam's example, this would then look more like this (not 100% >>>>>>> happy with git+git but it's nicer than handling the special case). >>>>>>> >>>>>>> # Custom roles using various protocols >>>>>>> git+ssh://[email protected]:ansible/role-disa-stig-rhel6.git,1.0 >>>>>>> git+https://git.acme.com/ansible/role-kibana.git >>>>>>> git+git://[email protected]:ansible/role-logstash.git >>>>>>> >>>>>>> This would end up with roles called e.g. role-logstash, which might >>>>>>> not be what you want, but I would prefer to keep the rolesfile simple. >>>>>>> >>>>>>> Will >>>>>>> >>>>>>> On Thursday, August 14, 2014 12:59:43 AM UTC+10, Michael DeHaan >>>>>>> wrote: >>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 13, 2014 at 10:57 AM, Sam Doran <[email protected]> wrote: >>>>>>>> >>>>>>>>> I like your syntax suggestion. That seems to fit more with the >>>>>>>>> ansible project. I agree that specifying the protocol would be a good >>>>>>>>> idea. >>>>>>>>> >>>>>>>>> Here's what it might look like: >>>>>>>>> >>>>>>>>> # Galaxy roles >>>>>>>>> adham.helal.authentication >>>>>>>>> agios.nginx-unicorn,1.3 >>>>>>>>> >>>>>>>>> # Custom roles using various protocols >>>>>>>>> disa-stig-rhel6,git,ssh://[email protected]:ansible/role-disa >>>>>>>>> -stig-rhel6.git,1.0kibana,git,https://git.acme.com:ansible/role-kibana.git >>>>>>>>> logstash,git,git://[email protected]:ansible/role-logstash.git >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Ansible Project" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/ansible-project/2946b30e- >>>>>>>>> e772-44af-9592-f0fec3f8da30%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Ansible Project" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/ansible-project/af2e9ef3-19e1-4379-a6b8- >>>>>> 439936841e7d%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com >> <https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxP4WCqUf4MbhytOO-A%3DfiTnn8Dtz%2BHUhxJ3RD%2BTNQB5Q%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxP4WCqUf4MbhytOO-A%3DfiTnn8Dtz%2BHUhxJ3RD%2BTNQB5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au > <https://groups.google.com/d/msgid/ansible-project/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxsMac6wEVHNVHTZimWaZVCR93rX0eO8qdVJgsiEUxznQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
