homebrew-pcloud

homebrew-pcloud copied to clipboard

Hi there.

I'm a mac power user, CLI lover, and as such I created my own tool to reinstall my mac: reinstall.sh.

I recently searched and found how to find, download and install the latest version of pCloud. No hash/version number to maintain, it automatically retrieves the latest version. You can find it in reinstall.sh or, in a simplified/explained version here.

Hope it helps.

@p-vernaeckt Thanks for pointing me towards the pCloud and reinstall.sh script! It looks like a really neat project 😄 I'm always looking to find new ways of automating software installs.

Quick Intro / background: I'm a DevOps Engineer, and have used many IaC tools including Chef, Ansible, Terraform, Puppet. (Of course I started out using a set of Bash scripts and functions too!). So, I'm no stranger to this space and the problems and solutions available. For many years I've been using a forked version of sprout-wrap (based on Chef Solo + soloist Ruby gem) to manage my MacBook. It has allowed me to quickly get set up on a new laptop across jobs & life transitions, so it's really been a great time saver when the need to reinstall or move to another machine arises. It also has been a huge time-sink and investment to maintain over so many years too! With all the changes to macOS over the years, Chef and other tools with complex dependency chains can break over time due to "bit rot" and OS / API shift. The latest changes from Apple like the CLang fork safety issue sure caused a lot of breakage & headaches. Sometimes the fastest way is to just use shell scripts indeed! (Maybe with a bit of glue and duct tape too! 😄 )

I've toyed around with the idea to make this Homebrew Cask auto-updating by automatically parsing out the pCloud API code like you suggest. It is certainly possible to make HTTP requests natively in Ruby and parse out the string. Also, the current design's maintenance overhead requires me to manually check the new download URL, find the new apicode, create a sha256 sum and update this Cask Tap. This process does take time, and can be annoying when pCloud constantly releases new versions quickly. However, I decided against it initially given these two principles:

1. Idempotency principle / API contract

• Always installing the latest version doesn't follow this principle
  • Any given run could install a new version
  • This can introduce change to the user's system that they might not expect or have planned for!
  • Example: brew reinstall cask terraform run on two separate occasions could install very different versions each with fundamental breaking changes that the user may not expect or want.
• Given the principle of the API contract, software packages tightly integrated and installed via Homebrew could break after any re-run of the brew reinstall command.
  • Actually Homebrew is a terrible example of this itself!
    • The brew install command is only Idempotent on a "time dependent" basis
      • After running brew update we cannot guarantee what new package changes were introduced by the community
      • Running brew install [--cask] <something> will always assume we want to install latest at the moment of runtime.
      • Many package managers provide a method to lock dependencies to a specific version. Homebrew does allow this, but it's not as simple to set up.
    • They are in the process now of deprecating the brew cask CLI commands
      • The --cask option will be needed soon on the various command verbs
      • This will effectively break their command line API
      • Any scripts or tools that rely on this behavior must now change! 🤦‍♂️
  • This tap has hardcoded apicode in a feeble attempt to regain some form of Idempotency (It's the best we can do without resorting to Homebrew versions for each new version that pCloud releases)

2. Security / Integrity of the Installer

• Downloading content from the Internet and not checking it using a checksum or gpg signature can be a security problem
• Not checking a downloaded binary makes the assumptions:
  • That the downloaded content is secure and can be trusted
  • That it has not been corrupted or modified by a potential attacker (e.g.: Inserting a virus payload)
• This tap has a hardcoded sha256 checksum to verify that the binary we download has not changed or been modified in transit

So these are the dilemmas we run into given these considerations, and the original discussion in Homebrew/homebrew-cask#57634 about the URLs with changing tokens pCloud uses to distribute pCloud via itself. It's not an ideal situation, and perhaps I may eventually decide to experiment with Homebrew versions such as: a pcloud-drive@latest and pcloud-drive@some-stable-version set of options.

After reviewing this again... Maybe this is now much more possible given Homebrew's new livecheck web-scraping capabilities. Also, the pCloud Release Notes page now has the publink download codes for both Intel & Apple Silicon versions.