OS X Workflow Updates

[NotMyself]

Fixes #42

Hey, this is Auth0Bobby from Twitch! I took some time today to try to get this building under OS X. The post-build bash script had a few issues that were perplexing and fun to track down.

First, it seemed as if the file might have been created on windows, this led to the file encoding being all b0rked and ? being added to some strings.

Next, the .editorconfig was forcing end_of_line to crlf on files. So editing the file in VSCode was inserting bad line endings for OS X. I updated the editor config to set it to lf for all .sh files.

[*.sh]
end_of_line = lf

Next, the fact that the plugins directory is located in ~/Library/Application Support/... was causing some commands to break. These commands were seeing the space as a separator and b0rking. Also, the script has a dependency on jq, but does not handle the case where jq is missing. I rewrote the entire script to simplify it and make it work as expected. Here is a brief explanation of what it all does.

echo 'Killing the Stream Deck process'
pkill 'Stream Deck'

 # use sed to get the uuid
uuid=$(sed -n 's/.*"UUID": "\(.*\)"/\1/p' manifest.json)
 # use parameter expansion to trip the suffix off the uuid to get the pluginname
pluginName=${uuid%.*}
# set a variable to the plugin directory so we don't have to type it over and over
pluginsDir="$HOME/Library/Application Support/com.elgato.StreamDeck/Plugins"
# set a variable to the current working directory
projectDir=$(PWD)


echo "Installing the $pluginName plugin to $pluginsDir"

# push the plugin directory on to the working directory stack
pushd "$pluginsDir"
# check of the plugin directory exists and nuke it if it does
[ -d "$pluginName.sdPlugin" ] && rm -r $pluginName.sdPlugin
# create the plugin directory
mkdir $pluginName.sdPlugin
# copy recursively the build output from the project directory tot he plugin directory
cp -R "$projectDir/bin/Debug/netcoreapp2.2/osx-x64/." $pluginName.sdPlugin
# pop the current directory off the working directory stack
popd

echo "Done installing ${pluginName}"

open /Applications/Stream\ Deck.app &

exit

Finally, the manifest.json had the CodePathMac value pointing to something that did not exist. I set it to the correct executable name.

{
    "CodePathWin": "SamplePlugin.exe",
    "CodePathMac":  "SamplePlugin"
}

Here is a short gif showing the build working on my machine. 😁

[csharpfritz]

This looks really promising. Adding @bradygaster to review on Mac

[hugodahl]

I managed to find where it was originally updated to using sed. @derekforeman made the change to use basic macOS/*nix commands in commit 4809fbb

I'm thinking it would probably be easier on the consumer of the template if we reduce the number of external dependencies to be installed if possible, or automate their retrieval and installation as much as possible.

[NotMyself]

@hugodahl are you referring to the use of jq?

[NotMyself]

Yeah OK, I found the line you were referring to and removed the dependency on jq in favor of sed.

[hugodahl]

Cool. I do think, jq would be much easier and cleaner, just like XPath would be if it were XML. That's one thing that thr npm platform does well. Having a package that does lpad and can break the world is not so great tho. You take the good, you take the bad, you take them both, and something something... ;)

[csharpfritz]

Is there a point where we put together a “prerequisites” script file that installs the .NET CLI and any other external tools we need? Jeff

…

On Jan 27, 2019, at 16:38, Bobby Johnson ***@***.***> wrote: Yeah OK, I found the line you were referring to and removed the dependency on jq in favor of sed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[NotMyself]

Maybe. At this point going down that road just to use jq on a single line of a single script seems like overkill to me.

[hugodahl]

I agree, at some point there may be the need to be a set of prerequisites, however, with multiple platforms, the complexity increases.

For example, do we want to maintain parity between platform specific scripts? Do we want to use equivalent utilities across platforms? Does each platform require a validator/maintainer?

Given those questions, there's also the option of requiring specific dev environment requirements. Perhaps require PowerShell core when that time comes, to potentially have a single script (Thursday's stream may shed some light on this option), with access to the package ecosystem and [relative] ease of writing our own extensions.

I'm not making a point or argument for or against any option. Just mentioning pain points of previous experiences to help ensure we have necessary information for the discussion.

[csharpfritz]

All very good points to consider. Thanks for the feedback Hugo! Jeff

…

On Jan 27, 2019, at 18:12, Hugo Dahl ***@***.***> wrote: I agree, at some point there may be the need to be a set of prerequisites, however, with multiple platforms, the complexity increases. For example, do we want to maintain parity between platform specific scripts? Do we want to use equivalent utilities across platforms? Does each platform require a validator/maintainer? Given those questions, there's also the option of requiring specific dev environment requirements. Perhaps require PowerShell core when that time comes, to potentially have a single script (Thursday's stream may shed some light on this option), with access to the package ecosystem and [relative] ease of writing our own extensions. I'm not making a point or argument for or against any option. Just mentioning pain points of previous experiences to help ensure we have necessary information for the discussion. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[derekforeman]

I think we have doubled up, #54. Odd about the line endings, I’m on a Mac. Happy to see have t move forward.

[hugodahl]

Agreed @derekforeman. I think that now makes 4 of us on macOS? You, @bradygaster, @NotMyself (aka Auth0Bobby) and me.

[bradygaster]

I wholly agree with this - less dependencies == good stuff.

I'm thinking it would probably be easier on the consumer of the template if we reduce the number of external dependencies to be installed if possible, or automate their retrieval and installation as much as possible.

[bradygaster]

Agreed @derekforeman. I think that now makes 4 of us on macOS? You, @bradygaster, @NotMyself (aka Auth0Bobby) and me.

It's good to know I'm not the only one trying to do this.

[bradygaster]

Thanks to everyone who contributed to enabling this on the Mac. It is great for @csharpfritz and I to have your support and knowledge in this space to get this going!

[NotMyself]

Happy to help @bradygaster @csharpfritz. I am not just a contributor, I am a user.

[csharpfritz]

Merging as approved by @bradygaster