Sunsetting DEPNotify integration

[erikng]

I'd like to sunset DEPNotify integration for a few reasons:

1. There are a few edge cases
2. Not every command is supported
3. I had to make assumptions that an admin may disagree with
4. There are now multiple flavors of "DEPNotify" that I have no intention of supporting.

If you object with this, please comment and we can discuss. I will leave this open for a week or two and then pull the integration, unless I am convinced otherwise.

In place will be some example scripts that an admin can use and recommended approaches for the JSON.

[flammable]

Those reasons sound pretty solid to me. I'm pretty sure I hit a few of those edge cases while building out our workflows.

With DEPNotify being integrated with NoMAD Login, IAs probably would have needed significant code changes to support that, too. I agree that it's best to separate out the DEPNotify support, since IAs is flexible enough to allow me to build out what I need on my own (that said, I appreciate the example code 😉).

Thanks, Erik.

[clburlison]

Simpler is better. I’m also not using this project so my opinion doesn’t really matter.

[vmiller]

I think this sounds reasonable. Reducing complexity should improve maintainability overall.

[MichalMMac]

Just yesterday I was thinking through following problem.

• There is installapplication.py script doing its stuff sequentially (f.e. installing packages).
• There is MDM pushing apps.
  BUT macOS installer installs one package at the time.
  -> This gives us race condition between package installs by installapplications.py and those form MDM.

As a result some package from setupassistant phase may not be yet installed when user logs in. Launch of DEPnotify by installapplication.py is therefore posponed until it gets to userland phase. This is not good when I need fullscreen DEPNotify just righ after first console log in.

This thread actually gave me right idea. I need my own LaunchAgents which if going to be part of bootstrap package along with DEPNotify.

Ripping out the code responsible for launching DEPNotify is OK imo. But it still may be good to retain capability to easily write status updates to DEPNotify control file about what installapplications is currently doing. Alternatively we would have to simple shell script for that after every package install.