-
Notifications
You must be signed in to change notification settings - Fork 19
Merge Packaging Overview
With merge packaging you merge your scripts and files into a copy of Shoes and create a completely new Application with no apparent ties to Shoes (some light work is required from you). The other styles of packaging installs Shoes and then runs your script.
Most of the Shoes documentation and the wiki talks about Apps which are shoes scripts bundled up with some files. Merge packaging is about Applications.
-
Real Installers All your users are used to running installers. Your app will have one: An
exefor Windows. Admgfor OSX. Adebfor Linux (rpm, pacman are options) -
Windows 10 This avoids the dreaded can not install on Windows 10 errors. Those errors occur in Windows 10 for the simpler packaging methods where the exe installs Shoes and attempts to use that to install and run a file extracted from a resource in the exe. If you think about it, that is virus behavior so lets not blame Microsoft too much. Merge packaging avoids that cleverness by not being clever. The installer installs your exe.
-
Hide Shoes Sometimes you don't want users to know that you used Shoes to create your application. You don't want them accidentally deleting Shoes or poking around with Shoes. There's no Shoes manual included with your app, no samples, no Cobbler. If they happen to have Shoes, your application won't use it - it won't even check.
-
Install System Wide On Linux, it was never an option to install Shoes in the System - It was always installed in user locations. On OSX it was not encouraged to be installed in /Applications but you could. A merged package application can be installed in the system. It's a good thing for some people.
Remember that side note: (some light work is required from you) ? It begins here.
-
Installers are Platform Specific To create a Windows installer you have to use a Windows machine. To create an OSX installer you need a Macintosh. to Create a Debian install (or and rpm install), you need a Linux box with the tools to do that. It's said that Installers can be tricky to get correct, particularly if you care about the user experience. That's True.
-
Icons While Shoes (and Linux) use icons that are png format, Windows and OSX have their own formats for icons. In fact you might want two icons: One for your application and one for your Installer. Windows uses .ico and OSX uses .icns formats. See Creating Icons.
-
Images The Windows Installer needs two images in the most ancient of .bmp formats. The OSX dmg needs a background image. You have to create them in the proper format and for the specified size
-
Practice, practice, practice Your first attempt at creating an Installer will probably fail or fail to please you. There's also the real possibility of bugs, yours and mine.
You can look inside the lib/package directory of Shoes to read the ruby scripts. They follow a general pattern.
- Copy Shoes (and it's Ruby)and any desired gems. Then copy your files to top. Merge! Then Magic and then call a Module/script to wrap that into an installer.
About the magic: The normal lib/shoes.rb is replaced with a minimal shoes.rb script that runs your starting script and then it deletes some things your end users can't use like the Shoes manual.
-
yaml files drive everything (or they should if you're serious).
-
command line scripts read the yaml and call the moodule with the magic inside. You don't have to write these tiny scripts but you should. See the links below and read the pages for the details.
-
GUI to build the Yaml. You can reach the GUI builder from the Cobbler menus. It a shiny way to create the yaml file for you - remember to save it! Yes it will call the magic Module for you if you 'deploy' but thats just incidental.
A wise developer likes to put all of an applications files in groups of directories (Folders) with just one at the Top - "foobar-project" for example. If you are used to Ruby standards you'd probably have a lib directory and a test directory. The problem is that Shoes has a lib and a static folder that's going to get copied and you really, really do not want to replace one of those because you named a file the same. The simple way is too look at what's in Shoes lib directory and pick a different name for your files in your lib directory. The static folder is less problematic if there is a collision but don't tempt fate. In fact you don't want your files to conflict with anything in the Top directory of Shoes. Of course, you can ignore the Ruby way and name your top level folders anything but 'lib' and 'static'. Bonus points if you think about how the 'fonts' directory can be used without changing the name.
Starting in Shoes 3.3.7, Shoes (i.e. your application will read `startup.yaml'. See the Setting section of the manual and Shoes 3.3.7 . You want a startup.yaml if only to change the application name. The rest of the settings might not matter to you and that's fine, there are all optional - but they default to Shoes names a behaviours and that might matter to you.
You need another directory or folder, one that is not part of or inside your 'foobar-project`. Call it 'package-foobar' for example. That's where your .exe or .deb or .dmg will be placed. It's also a good place for those installer required background images, icons, packaging yaml files and your own packaging scripts.
For example here is my 'ytm' app directory
~/Projects/ytm$ ls
README.txt Ytm-license.txt ytm.rb ytmsec.csv.sav
TODO.txt ytm.png ytmsec.csvOnly one Shoes script, ytm.rb, a csv and some text files. It should noted that this is a lousy place to put files that your script will write too? Why? Because your user can't write to files in system space. Bad Developer! For Shame!
Here is my 'ytm-package' directory.
:~/Projects/ytm-package$ ls
dmg.sh installer-2.bmp osx-background.png win-merge.rb ytm.icns
fpm.sh lin-merge.rb osx-merge.rb win-ytm.yaml ytm.ico
installer-1.bmp lin-ytm.yaml osx-ytm.yaml Ytm.appThe Ytm.app and dmg.sh is leftover from packaging on OSX. fpm.sh is leftover from a linux packaging. The yaml files are just platform specific variations. The ruby scripts are used for command line driven packaging after the yaml is mostly correct because it's much faster for me to use them than the GUI.