Necessary to make installing personal dotfiles a first class citizen
like many of the other install scripts. Having one's own dotfiles as
part of the machine setup helps ensure the shell is configured properly
especially when it comes to dealing with language specific dependencies
for Ruby, Rust, Node, etc. This reduces duplication within this project
-- and the macOS Configuration project -- from having to know all of
these details when settings can be defined within one's own dotfiles
once.
Necessary to provide a single source of truth for installing Node
dependencies. This used to be managed by the Yarn Setup project but
that project is being deprecated in favor of this project.
Necessary to provide a single source of truth for installing Ruby
dependencies. This used to be managed by the Ruby Setup project but
that project is being deprecated in favor of this project.
Necessary to implement the installation of Rust and associated crates
which can be used by downstream configurations. This functionality was
originally part of the macOS Configuration project but has been moved
here to provide a common foundation in which to build upon.
Necessary to ensure mas is installed before executing the script. This
reduces the strain on downstream projects/scripts from having to do
this check. This was previously part of the macOS Configuration project
but has been moved here as central location for core functionality.
Necessary to define the installation of Homebrew via a single function.
This was originally part of the macOS Configuration project but is now
located here instead.
Necessary for answering CPU of current machine when determining what
kind of functionality should be used when executing scripts on Silicon
or Intel based hardware. In this case, it'll answers "M1" when using an
Apple Silicon chip. For Intel based machines, nothing will be answered
since they use multiple "Processor" fields.
Resolves the following from happening:
Error: Calling `brew list` to only list formulae is disabled! Use
`brew list --formula` instead.
Includes a correction for the plural form for `casks` as well.
Resolves the following warning when using Homebrew 2.5.0:
Warning: Calling brew cask list is deprecated! Use brew list
Removed conditional checks for the Skitch, Witch, and OpenEmu
applications since they are no longer supported.
Was originally removed in this commit (a895090ca9) and has been
restored in order to handle situations where we have only a single file
install.
For example, the MacOS Config project needs this function in order to
properly install the Pathogem (Vim) file.
Modifies and renames the original `install_file` function so it
calculates install path based on application name. This ensures
`install_program` has the same behavior as found with similar install
functions:
- `install_dmg_app`
- `install_dmg_pkg`
- `install_zip_app`
- `install_zip_pkg`
- `install_tar_app`
These tools were originally necessary for some of the Homebrew
applications to install successfully (especially Elasticsearch) but
those requirements are no longer necessary. This also reduces the setup
friction by requiring less manual work on behalf of the installer.
Some apps are binaries packaged within a DMG, zip, etc. that have no
extension but are executable. These are meant to go in the
`/usr/local/bin` folder.
This corresponds with the code found in the `installers.sh` file (see
the `install_app` function).
Avoids displaying the following warning in the logs when checking out a
specific version of a project for install purposes:
You are in 'detached HEAD' state. You can look around, make
experimental changes and commit them, and you can discard any
commits you make in this state without impacting any branches by
performing another checkout.
If you want to create a new branch to retain commits you create,
you may do so (now or later) by using -b with the checkout command
again. Example:
git checkout -b <new-branch-name>
HEAD is now at f836f876a178 Added version release changes.
- Oracle makes it difficult to download the Java SE Development Kit as
an offline download because the license must be accepted first. The
JDK is important to have installed as several Homebrew apps require
it to exist first.
- This provides a prompt for checking that the Java SE Development Kit
has been installed before proceeding as the original way of
installing it assumed you had visited the Oracle web site and
accepted the license.
The install-all command does not reflect that the `bin/install_homebrew` file was split into `bin/install_homebrew_formulas` and `bin/install_homebrew_casks`, and therefore fails to install.
- Discovered some applications, packaged in zip file format, would
extract to a sub-directory. This was problematic because all zip app
installs previously assumed the app would be unzipped in the current
directory. This fixes that situation where an app might be located in
a sub-directory or several sub-directory deep.
- The easiest fix for this problem would have been to the `-j` option
for *junk* paths via unzip: "The archive's directory structure is not
recreated; all files are deposited in the extraction directory (by
default, the current one)." ...but some zip files, when unzipped, run
executable code that creates the sub-directory structure dynamically
which makes the `-j` option not viable.
- The solution used to fix this problem uses `find` to determine if the
application to install is in a sub-directory. If so, then the app is
copied to the root folder (i.e. $MAC_OS_WORK_PATH) so the script can
install as it has done in the past. Because the file copy is executed
only if `find` finds something, this makes the copy optional for sub-
directories and is a no-op for standard zip files with no sub-
directories.
Discovered that some zip app downloads use executable scripts to
build for the particular machine when unzipped.
http://earthlingsoft.net/UnicodeChecker/index.html
- These scripts default to calling out to scripts of the same name as
defined by the custom configuration project (i.e.
`$MAC_OS_CONFIG_PATH`).
- This helps ensure the scripts in this project can be run
appropriately even if the custom configuration project hasn't fully
implemented all scripts yet.
- This also helps illustrate what scripts are necessary when creating a
custom configuration.
