Installation page ease of use

[ChucklesOnGitHub]

I was adding the package used in the sockets tutorial to the list and had some thoughts:

• Having the package installation repeat for each different package I think is unecessary, we can unify in one. I've done this and will submit PR, see if you like it.
• As the list grows, we could specify which packages are essential (starter pack and onix1 design that installs onix1 librarary), and which for specific functionality
• We could provide a zip verison of the bonsai docs installation folder for users to download in assets/downloads so they install everything at once using the Setup executable, and specify how to use it in the Bonsai installation section. @bparks13 Is this possible to re-create the zip in assets automatically when the installation folder changes? Double-clicking the Setup file is the easiest way for users to get started and also helpful for production when they set up ready-installed PCs.

[cjsha]

Regarding the first two bullet points: I originally had that same thought, I agree. You have a better sense of when the users need hand-holding. If this isn't something where we need to go package-by-package, then let's go with what you suggest.
Regarding that third bullet point, I'd be concerned about having to update that environment every there is a new version of OpenEphys.Commutator, OpenEphys.Onix1, or Bonsai.StarterPack. Maybe there is a way to make sure the Setup script always downloads the latest package.

[bparks13]

I just ran the PR, and I agree with the changes that are present. I think we should have another issue created for the third bullet point and think about the implementation a little bit more before we add it in. Overall, I think it would be best if we did keep it as a static configuration (i.e., we would have to go in and manually update it when any of the packages are updated). The reason is similar to what we are doing now with pointing the docs to the source code at specific tags; we need to maintain control over whether or not the example scripts and workflows will run with the specific configuration we ship in the docs. Otherwise, there might be a breaking change in one of the updates that we don't catch that could cause issues downstream.

@ChucklesOnGitHub regarding your question about whether or not we can create a zip-folder of the installation folder; probably, I haven't done that before so I would want to test out a few different methods to see what would work best. My first thought is we just have an extra step in the GitHub actions for the docs repo that checks out that specific folder, creates a zip folder, and packages it in the HTML artifact. This would ensure that we are using whatever the most recently tagged version of the source code (note: this would not update until we point the submodule to a new tag, which aligns with what I was mentioning earlier about maintaining compatibility). Happy to discuss other options though!

[cjsha]

I think the people at Bonsai might include warning/error messages in the process of SVG exportation if the workflows don't compile correctly. bonsai-rx/docfx-tools#18 This would notify us if there is a breaking change in the workflows (due to updates in the latest packages, for example). If/when we have automated workflow validity checking, I think that checking should occur with the latest versions of the released software in which case it makes sense to set the config file to create the environment with the latest OpenEphys packages, if possible.