15:08:19 #startmeeting ansible core plublic irc meeting 15:08:19 Meeting started Thu Apr 9 15:08:19 2020 UTC. 15:08:19 This meeting is logged and archived in a public location. 15:08:19 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:08:19 The meeting name has been set to 'ansible_core_plublic_irc_meeting' 15:08:32 #topic https://github.com/ansible/ansible/pull/68288 15:09:07 no one? 15:09:24 Me 15:09:28 me ... 15:10:13 +1 from me, been wanting a 'non dependencies' requiresments for roles for long time, ony issue is now we have 'dual requirements.yml' that handles roles AND collections 15:10:58 i would standarize on that format from now on 15:11:18 but also, not make this a runtime issue, this should be 'on install' 15:11:46 whichi s what i belive the PR does , but the docs seem to hint otherwise 15:11:53 The current implementation only works on install yes. 15:12:35 `Dependencies installed that way, depending on other factors described below, will also be executed **before** this role is executed during play execution.` or im just misreading this 15:12:38 I tried my best do update the documentation to reflect that meta/requirements.yml are only on install and put that as the first point above meta/main.yml explanations 15:12:47 This if for meta/main.yml 15:13:01 https://github.com/ansible/ansible/pull/68288/files#diff-65f23e36b55ff5dbaa5e425562e97703R371 15:13:05 but that would be another instance of 'dependencies' .. i would rather have it INSTALL ONLY, no efect on runtime 15:13:06 i think the test should go into a new target dir 15:13:08 vs https://github.com/ansible/ansible/pull/68288/files#diff-65f23e36b55ff5dbaa5e425562e97703R378 15:14:22 bcoca the updated doc explain how to use meta/requirements.yml which only install dependencies and have no effect on runtime. 15:14:34 I did keep the old documentation about meta/main.yml 15:15:01 k, that works for me, pending full review 15:15:05 jtanner Why? 15:15:13 it's a new usecase 15:15:23 we shouldn't overload a test target with multiple usecases 15:15:26 jtanner: we normally have many use cases per target 15:15:35 we do, but that doens't make it right 15:15:40 the targets are per 'module/plugin/utility' 15:15:57 in some cases, but not always 15:16:00 making targets == use case breaks current pattern 15:16:08 I assume this has the same format as any other requirements.yml? 15:16:10 it's not a consistent pattern 15:16:17 cyberpear yes 15:16:27 jtanner: agreed, but i thought we were working to consolidate it, not break it more 15:16:35 * cyberpear has been creating such files in roles for some time 15:16:44 no, we're trying to make intentional coverage rather than incidental 15:17:06 jtanner: that is unrelated to target organization afaik 15:17:06 consolidation / normalization / patternization isn't a current goal 15:17:37 i've given my suggestion. take it or leave it 15:17:56 one thing i learnt during migration is that targets 'should' follow the 'tool' pattern, not use case , but i think this is tootally diff discussion and requires mattclay 15:19:28 cyberpear: thre are actually2 formats right now afaik 15:23:26 DaazKu: i would also add version added tags to docs, but otherwise, lgtm 15:24:13 bcoca Sure. Just gimme the version and where it should be added and I'll do it 15:24:43 version would be 2.10 15:24:50 `.. versionadded:: 2.10` 15:24:57 ^ that is the rst notation 15:25:07 you'll see examples of it in docs already 15:25:11 Thanks. 15:26:56 if noone else wants to weigh in on that one. .. 15:27:03 #topic Open Floor 15:32:33 #endmeeting