docs_working_group_aka_dawgs
LOGS
14:30:30 <acozine> #startmeeting Docs Working Group aka DaWGs
14:30:30 <zodbot> Meeting started Tue Jun 30 14:30:30 2020 UTC.
14:30:30 <zodbot> This meeting is logged and archived in a public location.
14:30:30 <zodbot> The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:30:30 <zodbot> The meeting name has been set to 'docs_working_group_aka_dawgs'
14:30:43 <acozine> #topic introductory chatter
14:30:45 <acozine> who's around?
14:30:52 <samccann> just barely here
14:31:04 <acozine> you wanna be a chair anyway? or a footstool?
14:31:30 <cbudz> I would prefer a nice chaise lounge
14:31:33 <acozine> heh
14:31:33 <felixfontein> hei :)
14:31:38 <acozine> #chair cbudz felixfontein
14:31:38 <zodbot> Current chairs: acozine cbudz felixfontein
14:32:01 <acozine> cbudz: you can choose the style and length of your chair
14:32:39 <cbudz> fantastic
14:32:48 <acozine> agenda for today begins with https://github.com/ansible/community/issues/521#issuecomment-648254778
14:32:52 <acozine> and continues below
14:33:02 <acozine> (below that comment, I mean)
14:33:42 <felixfontein> I was working a bit on the Ansible porting guide generation
14:33:43 * gundalow waves
14:33:48 <felixfontein> (next to changelog)
14:33:54 <acozine> hey gundalow!
14:33:56 <acozine> #chair gundalow
14:33:56 <zodbot> Current chairs: acozine cbudz felixfontein gundalow
14:34:18 <acozine> #topic porting guide and changelog updates
14:34:21 <felixfontein> the code is in https://github.com/ansible-community/antsibull/pull/103 and an example in https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f
14:34:25 * samccann life goal to be a comfy cushion
14:34:42 <felixfontein> (the porting guide is at the bottom: https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst )
14:34:58 <baptistemm> samccann: I can have look, I know this is not documented by my PR
14:35:06 <felixfontein> while working on that, I had some questions, which I put into the agenda :)
14:35:12 <acozine> hi baptistemm!
14:35:16 <acozine> #chair baptistemm
14:35:16 <zodbot> Current chairs: acozine baptistemm cbudz felixfontein gundalow
14:35:36 <baptistemm> hó I'm involved in an unexpected meeting
14:35:45 <acozine> yep
14:35:56 <acozine> speak up at the right (or wrong?) time and you get sucked in
14:36:14 <acozine> don't worry, we're a nice group
14:36:36 <acozine> felixfontein: those are good questions
14:36:58 <samccann> thanks baptistemm !!
14:37:01 <felixfontein> I guess there's the general question what will happen with the Ansible documentation now that ansible-base and ansible can (and will) diverge
14:37:15 <acozine> I do think we'll need a way to allow separate access to the ansible-base porting guide
14:37:25 <samccann> agree
14:37:33 <felixfontein> I guess this affects all of https://docs.ansible.com/ansible/
14:38:07 <acozine> the module docs are a separate section already
14:38:34 <felixfontein> yes, but if ansible 2.13 is based on ansible-base 2.12 (for example), it will get more fun
14:38:41 <acozine> "fun"
14:38:49 <felixfontein> also when ansible-base 2.10 is out, while ansible 2.10 is not yet out (which will happen this fall)
14:38:55 <felixfontein> yes, "fun" indeed :)
14:39:16 <felixfontein> I don't know whether this topic was already discussed internally
14:40:28 <acozine> yeah, we need a general page of "here are the two ways to use Ansible in the collections ecosystem - as an integrated package from PyPI, or as a pick-n-mix system of an ansible-base and a set of collections"
14:41:40 <bcoca> why initially we were not keeping 'ansible' as a name, only ansible-base and ansible community distribution, but since we are now 'reusing' ansible .. it gets back to being very confusing
14:41:50 <acozine> and an ansible-base-specific changelog is part of that
14:42:20 <felixfontein> bcoca: indeed! especially since ansible-base and ansible are not synchronized
14:42:59 <acozine> hmmmm
14:43:00 <bcoca> why i keep calling it ACD to try to keep the confusion from growing
14:43:02 <felixfontein> so maybe a lot of stuff has to be moved to https://docs.ansible.com/ansible-base/, and https://docs.ansible.com/ansible/ will be something new?
14:43:16 <felixfontein> bcoca: me too, and them I'm told all the time that ACD shouldn't be used anymore ;)
14:43:48 <felixfontein> that would be terrible for SEO though, break a millin links, and even more confusing for users
14:43:54 <acozine> yeah
14:43:57 <felixfontein> *million
14:44:14 <bcoca> well, we are breaking links anyways ....
14:44:31 <felixfontein> bcoca: the module links yes, but now everything else is on the line too ;)
14:44:43 <acozine> it's more the SEO I'm worried about
14:45:02 <bcoca> you cannot sell a car and still call it a motorcycle, we can keep the 'old docs' and just reference it as EOL and point to the 2 NEW products
14:46:11 <felixfontein> is there a possibility that ansible (i.e. ACD) will change its name again until september? (not that I want this)
14:46:11 <acozine> I think we maintain the docs at `/ansible` and start a new section at `/ansible-base` as part of an evolution
14:46:48 <acozine> there are two parts to this discussion
14:47:05 <acozine> one is about "how do we accurately document versioning in the new ecosystem"
14:47:16 <acozine> and the other is about "how do we help users find the documentation they need"
14:48:09 <acozine> and there's a fundamental question about what do we want to encourage people to do/read/see
14:48:34 <baptistemm> samccann: cidr_lookup is not a filter that's why I did not document it. It's a parameter for ipaddr
14:49:06 <acozine> do we want to encourage using the integrated package, whatever we call it? or do we want to encourage people to "build their own" from collections
14:49:18 <felixfontein> acozine: an interesting question is also whether the ansible-base docs will contain documentation of the ansible.builtin modules/plugins
14:50:05 <acozine> we've committed to backwards compatibility of a kind, providing a "kitchen sink" option
14:50:35 <acozine> felixfontein: that is also tied into this question of what behavior we want to encourage
14:50:37 <felixfontein> and someone decided that the kitchen sink solution re-uses the old name
14:50:48 <acozine> yeah
14:51:23 <acozine> that's at least partly for SEO purposes
14:52:21 <bcoca> acozine: but we also commited to NOT be backwards compatible with same kitchen sync ... we have many promisses at odds with each other
14:53:11 <bcoca> acozine: which i know puts docs team in really bad position of trying to write down the truth and yet still comply with the marketing
14:54:37 <acozine> bcoca: that's the "accurately document" part of it in tension with the "encouraging certain behavior" part of it
14:55:28 <bcoca> he, as expected from docs .. much better wording
14:55:38 <felixfontein> :)
14:57:40 <acozine> the trouble is, I'm not sure what behavior we want to encourage . . . do we want people to embrace the build-your-own ethos? In that case, the integrated package is ONLY for limited backwards compatibility (not that all old behavior is still included, but that you can install most modules in a single package)
14:57:41 <samccann> thanks for looking into it baptistemm
14:58:26 <felixfontein> acozine: that's a good question. is that something that RH management wants to decide? or that the community has to decide? or core team? or ...?
14:58:42 <baptistemm> samccann: I wonderered if it would not have beeen easier to write code to export all filters and function and put a heading for each of them
14:58:43 <samccann> last I heard, marketing wants to encourage Ansible, not ansible-base
14:58:55 <baptistemm> samccann: I can document them in another PR
14:59:06 <samccann> thanks baptistemm !
14:59:21 <acozine> baptistemm: I have a few grammar "nits" on that PR - I'll add them as suggestions
14:59:51 <baptistemm> acozine: even in French I usually do typo, I won't be offended that you correct my wording
15:00:35 <felixfontein> samccann: so marketing wants people to use Ansible (and not ansible-base + modules), even though that's not Supported?
15:00:35 <acozine> on the question of the Porting Guide, though, I think we need to build the ansible-base Porting Guide by itself for each version, and we also need to build the correct version into an all-inclusive Ansible Porting Guide for the PyPI package
15:01:21 <acozine> from one source, two output pages
15:01:22 <felixfontein> acozine: I agree, the ansible-base porting guide should be a separate document (that can be 'included' in the ansible porting guide)
15:01:26 <samccann> felixfontein - this comes from 3 months ago discussion so we'll need to check back and see what current thinking is, but yeah, last i heard we didn't want to encourage ansible-base + one or two collections as the common user experience
15:01:53 <samccann> portingguide - sounds like ... a POLL to me!
15:01:55 <samccann> :-)
15:01:59 <felixfontein> lol
15:02:11 <acozine> heh
15:02:16 <samccann> i'm here for realz now... aren't you glad?  :-)
15:02:19 <acozine> #chair samccann
15:02:19 <zodbot> Current chairs: acozine baptistemm cbudz felixfontein gundalow samccann
15:02:28 <acozine> now you can create a poll!
15:02:46 <samccann> is there some special way to create one?
15:02:54 <felixfontein> I guess it comes kind of automatically from when the ansible-base docs end up in docs.ansible.com/ansible-base, and the ansible-specific docs need to move out of ansible/ansible
15:03:07 <felixfontein> not that I know of
15:03:09 <acozine> samccann: oh, maybe not
15:03:17 <acozine> I thought it might involve Special IRC Powers
15:03:28 <bcoca> acozine: the problem is that diff groupins of 'we' want diff things and are going in diff directions
15:03:29 <samccann> POLL : have an ansible-base porting guide as a separate document, with that same information also pulled into the Ansible porting guide... +1 if you agree
15:03:31 <baptistemm> poll on irc I doubt this is possible
15:03:33 <felixfontein> nope... just write `POLL:` followed by the question
15:03:42 <felixfontein> +1
15:03:46 <acozine> homemade polling
15:03:47 <samccann> +1
15:03:48 <acozine> +1
15:03:55 <felixfontein> ansible-base already has its own changelog
15:04:06 <bcoca> i would go further, separate ansible-base as its all new 'own docs'
15:04:30 <samccann> don't mess w my poll dude!  That's a separate, deeper discussion
15:04:32 <samccann> :-)
15:05:01 <felixfontein> bcoca: I guess a lot of docs belong to ansible-base, while some belong to ansible, and there will be a lot of inter-linking (which will be especially fun when versions diverge a lot)
15:05:48 <felixfontein> also f.ex. filter docs: some of them are not part of ansible-base - should they be documented in ansible-base, or not?
15:05:49 <samccann> #info have an ansible-base porting guide as a separate document, with that same information also pulled into the Ansible porting guide - poll 3 agree, 3 didn't vote
15:06:04 <acozine> heh, slackers
15:06:08 <samccann> #info ansible-base has its own changelog.rst already
15:06:09 <samccann> heh
15:06:31 <samccann> are we done with porting guide conversation?
15:06:31 <felixfontein> https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst
15:06:43 * baptistemm can'tvote on things he does not understand
15:07:02 <felixfontein> samccann: I guess so, well, as much as we are done with the general topic of docs separation ;)
15:07:03 <acozine> felixfontein: yeah, I was working on the Filters page, and there are quite a few marked with "these filters have moved to X collection" . . .
15:07:12 <acozine> baptistemm: that is very good and honest of you
15:07:34 <felixfontein> bcoca: did you already work on making filter/test/... plugins documentable?
15:07:47 <bcoca> yes
15:07:53 <baptistemm> acozine: my manager is not always that I that honest :)
15:07:56 <samccann> what topic are we on now?
15:08:02 <acozine> felixfontein: what did you mean by `every new ansible version can have new porting guide entries (should only be deprecations though)`
15:08:24 <acozine> samccann: still the changelogs/porting guides
15:08:30 <samccann> thanks :-)
15:08:40 <felixfontein> acozine: collections can deprecate things in minor releases, and since ansible releases can contain newer minor (though not major) releases of collections, new deprecations can show up all the time
15:09:16 <acozine> ah, I see
15:09:24 * baptistemm forgot word happy
15:09:34 <acozine> baptistemm: ah, that makes more sense
15:10:04 <felixfontein> in theory collections could also add breaking_changes, major_changes and removed_features changelog entries in minor versions (even though they shouldn't!), so these could also show up later in a porting guide
15:10:12 <felixfontein> that's why I added a section in the porting guide for every release
15:10:18 <felixfontein> (resp. for every release that has content)
15:10:35 <samccann> hmm I thought breaking changes in a collection had to be a major release wrt semver?
15:10:37 * acozine goes back to look at the sample page
15:10:42 <samccann> link?
15:10:59 <felixfontein> https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst
15:11:28 <samccann> #info sample porting guide https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#file-porting_guide_2-10-rst
15:11:32 <felixfontein> for the porting guide, I grouped first by category (breaking change, deprecated, ...) and then by collection
15:12:14 <felixfontein> IMO it makes more sense, since usually people are most interested in breaking_changes and don't want to read the whole thing just to find all breaking_changes from all collections
15:12:30 <samccann> yeah it makes sense to me as well
15:13:32 <samccann> gosh we have a lot of nagging to do to get usable changelogs from all these collections
15:14:20 <felixfontein> samccann: indeed. and a list of links for the ones who don't want to use antsibull-changelog or provide a changelog.yaml file
15:14:26 <samccann> what do folks think is the best approach? Log an issue in each collection?
15:14:26 <acozine> the organization looks good
15:14:46 <felixfontein> samccann: probably compiling a list of things we need to know first, and then create an issue in every collection
15:14:52 <felixfontein> or something equivalent for collections not on github
15:15:15 <samccann> do we have a list of things we need to know? :-)
15:15:39 <felixfontein> I'm not sure, we have some items probably, but I'm not sure we know whether that's all or whether we forgot something ;)
15:15:53 <felixfontein> it's probably also a good time to create a list of repository URLs
15:16:31 <acozine> felixfontein: there's something odd about the internal links on that page - if you click on a heading in the text, you jump back to the top TOC
15:16:32 <samccann> ok how about I create an issue on ansible-collection/overview and we can compile a list there ?
15:16:41 <acozine> samccann: that sounds awesome
15:17:23 <felixfontein> acozine: it sends you to the toc entry, and click that one sends you back to the section. that's how github is rendering .rst files apparently
15:17:31 <felixfontein> samccann: sounds good!
15:17:48 <samccann> #action samccann create an issue on ansible-collection/overview to gather the list of things we need to know to get collection changelogs into the Ansible changelog.rst  - in preparation for creating issues in each collection repo on what they need to do
15:18:00 <acozine> ahhh, it's rst, not the generated html, right
15:18:07 <felixfontein> the resulting data should in the end live near to https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in
15:19:00 <felixfontein> I guess for the ACD changelog, we also want to be able to write some text for every release?
15:19:08 <samccann> #info ansible build data (aka included collections ) - https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in
15:19:46 <felixfontein> (that's displayed at the beginning of a version's section, like here before 'Unchanged collections': https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f#v2-10-0a2)
15:20:58 <acozine> hm, we didn't record the discussion about the porting guides, did we?
15:21:38 <felixfontein> the vote got #info'ed
15:21:39 <samccann> we added an info about there being a separate porting guide for ansible-base etc. I don't know what else was final info
15:21:55 <acozine> ah, perfect
15:22:07 <felixfontein> I guess the main problem is the amount of non-final information :)
15:22:15 * acozine breathes in, breathes out
15:22:18 <felixfontein> resp. the non-final information which we have to work with
15:22:36 <samccann> lol
15:23:01 <samccann> yeah usually I would sprinkle a few more infos but I was behind today... so *shrug*
15:23:12 <baptistemm> I thought this non-final info was just in mty company
15:23:22 <felixfontein> baptistemm: I think it's specific to humanity
15:23:38 <samccann> #info how and when we split anible-base docs from ansible (aka acd) docs is a deeper discussion for later
15:23:38 <felixfontein> there's not enough infos for non-humans ;)
15:23:40 <acozine> baptistemm: sadly, no
15:23:56 <felixfontein> yes, though not for much later probably
15:24:16 <felixfontein> when ansible-base 2.10 is released, ansible 2.10 will follow ~1 month later (according to current extremely tentative schedule)
15:24:20 <samccann> #action samccann add Splitting ansible-base from Ansible docs to agenda
15:24:27 <baptistemm> I'm heading to the pool, but I'll work on missing ippadr fonction, it's fun to test code
15:24:30 <felixfontein> I guess the problem should be better solved until then :)
15:24:39 <samccann> thanks so much baptistemm !!
15:24:42 <felixfontein> enjoy the water!
15:24:44 <baptistemm> no prob
15:24:46 * samccann wishes she was heading to the pool
15:24:49 <acozine> we've been talking for a while about changing the overall organization of the documentation to focus more on users than on products
15:25:21 <samccann> yeah we can get into that in a separate meeting. It might even need its own supplemental meeting just to focus on that for an hr
15:25:43 <acozine> I suspect we could have an all-day summit on the topic ;-)
15:25:46 <baptistemm> I don't want to sound harsh and I don't know the whole storey, but the ansible docs is a bit patchy, lot of stuff scattered
15:25:47 <samccann> oooch
15:26:01 <samccann> yeah that's part of the problem baptistemm
15:26:05 <acozine> baptistemm: that's great feedback, thanks
15:26:29 <acozine> I agree it's hard to find things
15:26:53 <baptistemm> I don't know how one people knowing nothingh about ansible could be driven to learning things in the correct order and with the correct amount of information
15:26:54 <acozine> if you have specific examples, please post them here (maybe after your swim)
15:27:13 <samccann> we have 3 min left
15:27:18 * samccann human clock
15:28:07 <acozine> baptistemm: yes, that's a hard problem
15:28:16 <acozine> samccann: woopsie
15:28:23 <samccann> we need to prioritize what needs to be done by ansible-base release, and what needs to be done by ansible release
15:28:58 <samccann> obviously not in 2 minutes but I guess my question is - do we want a supplemental meeting this week? (it being a short week in the USofA)?
15:29:04 <felixfontein> I guess docs.ansible.com/ansible/latest/ must only switch to 2.10 once ansible 2.10 is released, so a new home for ansible-base needs to be found until its release
15:29:27 <felixfontein> I might not have much time for another meeting, though I'll probably listen in
15:29:35 <samccann> or do we want to continue here for another 20 min or so and try to list priorities?
15:29:47 <acozine> felixfontein: we may have even a little more time, it sounds like we may release 2.10 without updating `latest`
15:29:54 <felixfontein> it might be a good idea to ask internally - like the core team, management, marketing, ... - what they think about this
15:30:20 <felixfontein> acozine: that's even worse ;) then docs.ansible.com/ansible/2.10/ would be docs for ansible-base, and not ansible
15:31:21 <samccann> my nickel - we won't have time to pull ansible-base out of the docs into its own home before it releases
15:31:54 <acozine> felixfontein: isn't that going to reflect reality for a while? when is the planned release of the PyPI `ansible` package?
15:32:19 <felixfontein> acozine: I think it is (very very tentatively) ~one month after ansible-base's current planned release, i.e. mid september
15:32:58 <felixfontein> how it continues depends on how fast (or not fast) ansible-base 2.11 will be released, and how fast ansible wants to release (no idea whether this has been talked about)
15:33:03 <felixfontein> gundalow: abadger1999: might know more
15:33:05 <samccann> #info ansible-base tentatively comes out in mid Aug, and Ansible (acd) in mid Sept (dates subject to change for sure)
15:33:44 <acozine> samccann: so, for your priorities list
15:33:52 <samccann> so someone who wants to use ansible-base is doing something like pip install ansible-base?
15:34:15 <acozine> or yum install ansible-base?
15:34:22 <samccann> yeah whichever
15:34:44 <samccann> i guess I'm still stuck on who's using ansible-base w/o ansible in that one month or so window
15:35:01 <acozine> samccann: my guess is, very few people
15:35:09 <samccann> and given very limited people to do this work, how does that fit into our priority list
15:35:17 <felixfontein> btw, for people using `pip install ansible` there will be some more challenges
15:35:25 <felixfontein> same for `pip install ansible-base`
15:35:38 <felixfontein> especially until ansible-2.10 is released
15:35:49 <samccann> if it's very little people using ansible-base on its own, can we just put a section in the porting guide (for ansible-base) on how to get it and say the docs still reflect full ansible for now
15:36:10 <samccann> felixfontein can you elaborate on the problems?
15:36:21 <felixfontein> https://github.com/ansible/ansible/issues/70348
15:36:38 <felixfontein> the problem is: if you have ansible-2.9 installed, and install ansible-2.10, your ansible binaries will be gone
15:36:45 <felixfontein> (that's due to the way pip works)
15:36:51 <felixfontein> if you install with pip, that is
15:36:59 <felixfontein> system package managers should do better
15:37:25 <samccann> is that a permanent problem?
15:37:29 <felixfontein> and if you install ansible-base next to ansible-2.9 (which pip won't disallow since they are different packages), you will end up with a broken installation
15:37:33 <acozine> ah, I think I saw this conversation yesterday - you have to uninstall first?
15:37:37 <felixfontein> yes
15:37:54 <felixfontein> once nobody is using ansible-2.9 or older anymore, or upgrading from a version before 2.10, the problem is gone
15:38:06 <felixfontein> but the change from pre-2.10 to 2.10+ will be rough
15:38:22 <samccann> #info pip install ansible-base will have a problem requiring users to uninstall first or use --force.. see https://github.com/ansible/ansible/issues/70348
15:38:47 <samccann> what happens when we go from ansible-2.10 to ansible-basee 2.11 for example?
15:38:55 <felixfontein> that will be no problem
15:39:11 <samccann> ok so this is just the upgrade problem... so should be in the porting guide, right?
15:39:20 <felixfontein> it's essentially a one-time problem - except that people don't upgrade right now, but over the next n years
15:39:24 <acozine> does this problem affect only `ansible-base`? or also the new, collections-based `ansible` package?
15:39:31 <felixfontein> so it will show up again and again for several years
15:39:34 <samccann> ooch
15:39:48 <felixfontein> acozine: it also (and in particular) affects the new ansible package
15:40:04 <felixfontein> if someone does `pip install --upgrade ansible` once ansible 2.10 is out, they end up with a non-working ansible
15:40:09 <samccann> #info this upgrade problem is only for pre 2.10 to 2.10+ upgrades, but users will do this at their own pace so needs solid docs 'somewhere' that will linger and be noticable to cover this
15:40:13 <felixfontein> (assuming they had 2.9 or older installed before)
15:40:24 <abadger1999> It's the tension from 2.9 or less to 2.10 or greater
15:40:35 <acozine> we need to add a big `Before you upgrade, check which version you have installed now. If it is <= 2.9, uninstall first` message in a bunch of places
15:40:45 <samccann> yep
15:40:48 <felixfontein> yes
15:40:51 <abadger1999> (typing slow, on phone, today, sorry)
15:41:22 <acozine> that seems like a priority PR
15:41:32 <samccann> #action samccann create a priority issue to track this upgrade problem in prominent places besides the porting guide
15:41:38 <abadger1999> @acozine: big +1 to that :-)
15:42:13 <samccann> what does pip install --upgrade ansible actually do?
15:42:26 <samccann> i would have thought nothing until ansible 2.10 comes out
15:42:36 <bcoca> https://github.com/ansible/ansible/issues/70348
15:42:36 <felixfontein> samccann: it first installs ansible-base (among other dependencies), then uninstalls ansible-2.9, and then installs ansible-2.10
15:42:57 <samccann> yes but not until 2.10 comes out right? (not 2.10 ansiblebase)
15:43:03 <felixfontein> samccann: and doesn't notice that installing ansible-base overwrote the binaries, and uninstalling ansible-2.9 also clears the binaries (and also the Python package) ansible-base installed
15:43:16 <felixfontein> so a lot of files from ansible-base are missing
15:43:37 <felixfontein> wiped by uninstalling ansible-2.9 (since it also provides these files)
15:44:48 <felixfontein> samccann: if someone installs ansible-base next to ansible-2.9, they destroy their 2.9 installation. same if these are installed in the other order. and if one is removed, the other one is left mostly dead
15:45:30 <abadger1999> @samccann Yes-ish.
15:45:32 <felixfontein> (this already happened in the past, probably multiple times; the problem I know about is the pypi package docker-py which was renamed to docker, and which both install the same Python module)
15:45:51 <acozine> felixfontein: ah, so we are in good company . . .
15:45:59 <acozine> or at least, we aren't the first to hit this particular snag
15:46:12 <felixfontein> acozine: yes. this came up as an issue for the docker_* modules for years
15:46:26 <samccann> ok maybe the best approach would be if y'all add 'this should be documented' comments to that issue so we know what kind of docs details to add?
15:46:43 <felixfontein> there's even code in the docker modules to tell the user that they apparently installed both packages, and that they have to remove both and then re-install one to make it work
15:46:43 <abadger1999> @samccann Right now there's pre-releases of ansible and ansible-base on pypi so `pip install --upgrade ansible` isn't broken yet but `pip install --upgrade --pre ansible` is  (as is specifying the version number explicitly: `pip install ansible==2.10.0a1`)
15:46:57 <samccann> or maybe yeah, like I said, I'll open a docs issue and ask y'all to add details in case I miss some
15:47:38 <felixfontein> abadger1999: it will be special fun when ansible-base 2.10 is released, and people install it with pip "next" to ansible 2.9 (or older)
15:47:51 <abadger1999> yeah.
15:48:23 <abadger1999> I asked in #pypa if there was a conflicts tag in pip a month or so ago for just that reason :-(
15:49:03 <felixfontein> was the result something like "yes there is, but pip ignores it"? (from what I remember from yesterday)
15:49:14 <abadger1999> The answer was, no there isn't.
15:49:15 <acozine> so the error folks would run into is `command not found: ansible-playbook`
15:49:21 <felixfontein> ah. in the end, same result...
15:49:28 <abadger1999> But we found the Obsoletes tag which is ignored by pip yesterday.
15:49:31 <felixfontein> acozine: yes
15:49:48 <felixfontein> abadger1999: ah, that's what I remembered then
15:49:53 <samccann> ok here's the issue -https://github.com/ansible/ansible/issues/70392
15:49:57 <abadger1999> Obsoletes and Conflicts are often intimately related.... until there's an implementation I wouldn't know if Obsoletes is sufficient or not.
15:50:03 <samccann> please add details there so we don't lose this thread
15:50:56 <samccann> #info tracking issue for upgrade problems  - https://github.com/ansible/ansible/issues/70392
15:51:16 <acozine> samccann: I added the error message
15:53:14 <felixfontein> I added a summary of what leads to destruction
15:53:19 <samccann> thanks everyone!
15:54:02 <acozine> now we've gone 23 minutes over
15:54:25 <acozine> in a good cause, though
15:54:38 <felixfontein> isn't that the case most times? :)
15:54:45 <acozine> yes!
15:55:32 <samccann> #info need to set priorities for docs for ansible-base release and ansible release
15:55:49 <samccann> open the floor?
15:55:59 * samccann ponders what that really means or came from
15:55:59 <acozine> #topic open floor
15:56:33 <acozine> it's from parliamentary procedure . . . Robert's Rules of Order, where the chair literally controlled who "had the floor" and so could speak
15:57:14 <acozine> don't know why I made that past tense
15:57:26 <samccann> yeah but wondering was it a literal floor that you had to stand in to talk
15:57:44 <acozine> probably
15:58:03 <acozine> in the days before audio systems, you probably needed to be in the middle to be heard
15:58:04 * felixfontein thinks of a floor with a trapdoor which can be used to get rid of the speaker if they talk too much :D
15:58:05 <samccann> and now that we used open floor to talk about... open floor...
15:58:11 <samccann> HAHAHAHAHA!!!
15:58:11 <acozine> heh
15:58:25 <felixfontein> "it's getting boring. let's open the floor!"
15:58:25 <acozine> it's the hallowed tech tradition of recursion
15:58:49 * acozine feels herself falling
15:59:00 <felixfontein> I'm glad our floor is virtual ;)
15:59:27 <acozine> me too . . . and someday someone is actually going to step onto the open floor and ask a question
15:59:29 <acozine> or make a comment
15:59:31 <acozine> or something
15:59:39 <acozine> virtually, of course
16:00:23 <acozine> but it seems today is not that day
16:00:42 <acozine> as always, chat welcome in the channel any time
16:00:55 <felixfontein> :)
16:01:04 <acozine> and anyone can add items to https://github.com/ansible/community/issues/521 for the next meeting's agenda
16:01:06 <acozine> just add a comment
16:01:36 <acozine> thanks abadger1999 bcoca cbudz felixfontein samccann
16:01:46 <acozine> and baptistemm in abenstia
16:01:52 <felixfontein> thanks a lot everyone! :)
16:01:52 <acozine> er, absentia
16:02:09 <acozine> #endmeeting