ansible_windows_working_group
LOGS
20:00:03 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:03 <zodbot> Meeting started Tue Oct 19 20:00:03 2021 UTC.
20:00:03 <zodbot> This meeting is logged and archived in a public location.
20:00:03 <zodbot> The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:03 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:09 <nitzmahone> bah
20:00:12 <nitzmahone> #chair jborean93
20:00:13 <zodbot> Current chairs: jborean93 nitzmahone
20:00:32 <nitzmahone> #info agenda https://github.com/ansible/community/issues/581
20:00:58 <briantist> howdy
20:01:14 <nitzmahone> Nothing other than the carried forward discussion on win_dsc stuff, so unless MKletz is here and wants to discuss
20:01:16 <nitzmahone> #topic open floor
20:01:20 <nitzmahone> Hey briantist!
20:01:35 <briantist> how's it going?
20:01:49 <nitzmahone> Same old :D
20:02:01 <nitzmahone> core 2.12.0rc1 is out
20:02:23 <nitzmahone> and we've started taking the shredder to devel
20:02:28 <briantist> woot!
20:02:38 <briantist> taking the shredder meaning what 👀
20:02:48 <briantist> what's being removed?
20:03:12 <nitzmahone> Oh just starting 2.13 work in general- the core setup stuff got a long-overdue makeover merged just a few minutes ago
20:03:43 <briantist> yeah saw that in the other channel, w h e e l s !
20:05:11 <nitzmahone> Well, at least we can make them now- we just have to get the upstream builds changed to actually deliver them (since we no longer directly own it)
20:05:33 <briantist> right
20:05:48 <nitzmahone> You can also directly invoke all the core CLIs via `python -m ansible playbook` eg now
20:06:30 <nitzmahone> (nice for those screwed up systems where the bin scripts/PATH doesn't match the Python env)
20:06:44 <nitzmahone> *cough* Mac homebrew *cough*
20:06:48 <briantist> yeah that's pretty cool
20:07:09 <nitzmahone> Nothing revolutionary, just some nice quality-of-life things that are long overdue
20:07:35 <briantist> it's also going to be nice for running from source maybe, in that right now for 2.12+ after using the hacking env, I have to do `python3.8 $(which ansible-test) ...` 😞
20:07:47 <nitzmahone> You can also do `pip install -e` now
20:07:53 <briantist> but.. that would also be solved by me getting a 20.04 distro set up and configured in WSL
20:08:12 <briantist> what does `-e` do for `pip install`?
20:08:19 <nitzmahone> We *think* we fixed all the problems that were breaking things for editable installs, so you don't *have* to use `hacking/env-setup` anymore
20:09:50 <nitzmahone> It's a standard-ish Python thing that basically does an in-place install to your current Python env with some `.pth` hackery. Essentially makes it behave like you'd run `hacking/env-setup` but it's persistent in the Python env
20:10:18 <nitzmahone> (eg once you've done it, it survives reboots, shell restarts, etc)
20:10:59 <briantist> ah.. hm, I like it NOT persisting, as it doesn't mess up my other ansible uses that still need 2.9 (😭)
20:11:05 <nitzmahone> So basically: `git clone https://github.com/ansible/ansible && pip install -e ./ansible`
20:11:40 <nitzmahone> Well, it's persistent only to that python env
20:12:15 <briantist> right, true, I could use a venv for that, seem cool! hadn't heard of editable installs before
20:12:18 <nitzmahone> Just another option Python folk have been asking for for a long time
20:14:19 <briantist> very cool
20:14:51 <nitzmahone> I wouldn't recommend sharing Python envs between ansible-core releases, especially as we start to get a little more stringent on dependency versions- could end up with some pretty weird behavior. That's the other nice thing about `pip install -e`, since it'll automatically ensure all the right runtime requirements are met (and install them if not)
20:15:23 <briantist> yeah, I have some improvements to make in my local dev environment for that!
20:15:56 <briantist> I'd also like to investigate the "dev containers" that vscode supports, and maybe move my whole ansible dev environment into a container
20:16:21 <nitzmahone> Regardless, `hacking/env-setup` isn't going anywhere anytime soon- we just wanted to get another option out there for the folks that like to do it the "standard" way. PyPA is making some investments/enhancements in that area as well
20:16:45 <briantist> right that makes a lot of sense
20:16:46 <nitzmahone> Yeah, I haven't tried that either, but it should be pretty straightforward
20:17:59 <nitzmahone> VSCode's Python debugger still doesn't hold a candle to pycharm/pydevd last I tried, esp for things that are critical to debugging ansible-core like fork/subprocess following
20:18:26 <nitzmahone> So I haven't spent a lot of time playing with it, since it wouldn't be able to supplant what I'm already using
20:18:40 <briantist> Jordan had a gist or something somewhere, outlining how he got live debugging working in vscode.. I need to find that again, I never did try it..
20:19:00 <nitzmahone> It's pretty straightforward for modules, if that's what you mean
20:19:02 <briantist> but I otherwise adore vscode for all my ansible stuff
20:19:19 <briantist> ah, no I'd want to use for stepping through controller code if possible
20:20:04 <nitzmahone> Yeah, unless they've fixed up some stuff since I last tried, it's pretty limited- it used to be as soon as a worker got forked off, you couldn't debug past that without some major manual hackery
20:20:16 <nitzmahone> (where that Just Works with pycharm)
20:20:36 <nitzmahone> Neither one of them can debug through the local connection plugin to actually let you debug a module "in-circuit"
20:21:07 <briantist> got it.. I never used pycharm. Actually I never really used python before getting into ansible stuff either
20:21:14 <nitzmahone> me either :D
20:21:23 <nitzmahone> C# 4 eva
20:21:30 <briantist> haha
20:21:54 <briantist> speaking of which, anything new and interesting on the core side that's Windows related?
20:23:18 <nitzmahone> Not in core 2.12 really- Jordan's made a few little tweaks to some internals, but all the fun performance stuff is blocked on some core plugin model rearchitecture that we have to make time for
20:24:02 <briantist> I am starting to worry about the future of Windows support with everything being so tied to Windows PowerShell
20:24:15 <nitzmahone> How so?
20:24:36 <nitzmahone> (I guess I mean: with what as an alternative?)
20:24:54 <briantist> PowerShell > 5.1 (what used to be called PowerShell Core)
20:25:25 <nitzmahone> Oh, whenever Microsoft actually ships something new as an option in the box, I think we're pretty well ready to roll with it
20:26:51 <nitzmahone> We just don't know exactly what it will look like until it happens, but I assume we'd do something ala interpreter discovery to select the right thing- Jordan's been staying on top of keeping the core exec wrapper and stuff working (or easily fixed to be so) under the newer PS versions.
20:27:18 <briantist> ok well that's good to know!
20:27:19 <nitzmahone> Lighting up interpreter discovery on Windows should be a few lines of code, based on where it is
20:27:57 <briantist> it would be nice to get it out sooner so that if you have pwsh installed already you can tell ansible to use it
20:28:24 <nitzmahone> IIUC the things that have been delaying a new Windows release shipping with a newer PS version are around compatibility, so the longer they wait, the easier it should be to ensure that everything "just works" under the new stuff
20:28:40 <briantist> though another problem is that most modules aren't tested in it so there might be compat issues too. would be cool to start testing against it with non-voting runs
20:29:02 <briantist> yeah, that sounds reasonable
20:29:20 <nitzmahone> You already can in a lot of places- I think nearly all the changes required for that to work have already been merged (at least for the PS6 series, and I think 7 didn't break any of it). We just don't have a lot of automated testing for it since it's not in the box yet
20:30:48 <briantist> gotcha
20:30:58 <nitzmahone> Our soft plan for that is whenever MS actually ships a new PS in the box as a default option, we'll add that host type to CI for both core and the Windows collections ASAP and run everything under the new PS version to see what's busted
20:31:39 <nitzmahone> So I wouldn't worry too much about it- hopefully we'll have everything green that's possible to be so well before the OS actually RTMs
20:32:04 <briantist> nice, thanks for the insight!
20:32:57 <nitzmahone> I was half expecting Server 2022 to switch to PS7, but they're apparently being very conservative about that still
20:33:18 <nitzmahone> (for which I have no complaint ;) )
20:33:18 <briantist> yeah I was kind of surprised by that too
20:34:06 <nitzmahone> Welp, I think I'm gonna go find some lunch- thanks for stopping by!
20:34:17 <nitzmahone> til next week...
20:34:18 <briantist> take care!
20:34:21 <nitzmahone> you too!
20:34:24 <nitzmahone> #endmeeting