Porter's packaging plan

[sestegra]

After discovering Porter, I would like to contribute to the creation of homebrew formula for macos.

However, porter binary needs to have its binary "companions" to be installed as relative to its path (aka PORTER_HOME):

• porter-runtime binary
• mixins folder with local and invocation binaries
• plugins folder with local and invocation binaries

Multiple porter calls create schema.json and some data folders like claims, credentials, parameters and results in PORTER_HOME.

For the following discussion, let's assume that:

• porter and porter-runtime could be categorized as core binaries
• mixins and plugins could be categorized as add-ons binaries
• data folders could be categorized as user data
• ~/.porter and %USERPROFILE%\.porter could be named home directory
• /usr/local and %PROGRAMFILES% could be named system directory

Before building a package, Porter needs a packaging plan for all supported systems that defines locations for core, add-ons and user parts.

So, I suggest that:

• core parts could be installed in system directory.
  With homebrew, /usr/local/bin/porter would be a symlink to /usr/local/Cellar/porter/<version>/porter
• user parts could be installed in home directory.
• add-ons could be installed in home directory.
  In fact, during a life-cycle of one porter revision, mixins and plugins could be installed and/or upgraded by different users.

What do you think about this idea?

[carolynvs]

@sestegra I would love help with a homebrew formula!

You have hit upon a bit of a problem with how Porter works today, we have assumptions that everything is in the same directory as the porter binary (unless the environment variable PORTER_HOME) is set. It's not standard and should be addressed. I am 100% on-board with having our current directory structure split up into

• user directory, by default ~/.porter though it would be controlled via the usual env vars such as $HOME, $XDG*, containing the installed mixins, plugins, cache and installation data
• system directory, with homebrew that would be/usr/local/Cellar/porter/<version>/, containing the porter client and runtime

Let me write up an issue that describes what needs to be done in Porter for this bit and I'll link it here. #1328 Let me know if you'd be interested in working on that issue! 😀

Sounds like we need a bit of refactoring in Porter itself before we can submit a formula?

[sestegra]

With PR #1329, a formula could be created to only install porter executable.

Nevertheless, PORTER_HOME should be fed by end-users:

• porter-runtime needs to be download via URL
• a dedicated porter command exists for mixins and plugins

We need to find a way to ease the feed of the local PORTER_HOME.

[carolynvs]

porter-runtime needs to be download via URL

Can you explain why we cannot download all supported runtimes (at the moment this is only linux-amd64) during installation? The runtime is independent of the client architecture, and eventually we will be creating multi-platform bundles, e.g. amd64 and arm64, with linux and windows support. Based on this, I believe we would need all possible architectures, unless you are thinking of having the bundle author decide when building which platform to build into the build and grab the runtimes dynamically?

a dedicated porter command exists for mixins and plugins

We have those already. Let me know if this was identifying a gap in what needs to be implemented!

We need to find a way to ease the feed of the local PORTER_HOME.

I don't understand what this means?

[sestegra]

porter binary should be zipped and packaged with LICENSE file.
porter binary should be named porter without OS and architecture in its name.

My first try for the packaging using Homebrew isn't well, see sestegra/homebrew-porter@1b38cbd
In fact, mv $binary_name, "porter" must be added in the install target.

[carolynvs]

Sorry, I'm not following. Are these just notes? Are you saying that in order to support homebrew we need to change how we publish the porter binary to our CDN?

I have created homebrew formula in the past that have not had a problem with distributing a single binary, no zipping or inclusion of the license. If things have changed, I wasn't aware of it.

[sestegra]

My comments were suggestions: no change on the way of building Homebrew package.
So, my commit is well enough.

brew info porter command reports the license.