Release-friendly workflow/plugin load paths

[scottyw]

To support running Lyra as a binary installed via brew and when built from source we need to change the load paths for workflows and plugins, based on both the current working dir and the dir in which the binary is located.

Brew lay files out like this:

lyra
└── 0.0.9
    ├── INSTALL_RECEIPT.json
    ├── LICENSE
    ├── README.md
    ├── bin
    ├── docs
    ├── examples
    ├── goplugins
    └── workflows

When built from source, the binaries are laid out like this (although we could change this if desired):

build
├── goplugins
│   ├── example
│   ├── foobernetes
│   ├── identity
│   └── puppet
└── lyra

When using go run cmd/lyra/main.go during development I think we can assume that is happening in the root of the project repo.

Below then, assume that WORKING_DIR refers to the current working dir and that EXECUTABLE_DIR refers to the dir containing the Lyra binary.

We need to load workflows from both of:

• WORKING_DIR/workflows
• EXECUTABLE_DIR/../workflows (to support brew and running build\lyra irrespective of working dir)

The search path for plugins, in order, is:

• WORKING_DIR/build/goplugins (to support both plugin and lyra development)
• EXECUTABLE_DIR/goplugins (to support running the built binary)
• EXECUTABLE_DIR/../goplugins (to support brew)

[thallgren]

Is there anything hindering that 'goplugins' resides under the 'bin' directory in the brew layout?
I don't understand the use case for WORKING_DIR/build/goplugins. The plug-in loader is always part of the Lyra executable so why would we need to consider WORKING_DIR for plugins?

[scottyw]

No problem I can think of with moving goplugins under bin in brew but I don't really know - anything worry you about that @ahpook ?

WORKING_DIR/build/goplugins is intended to support running with "go run ...".

[jdwelch]

Seems sane to me; +1

[ahpook]

It's a little weird to have subdirectories of bin/ (of 100 brew packages I have installed, only one has a subdirectory there), but it's not going to hurt anything. The only brew-specific thing to make note of is that the user will normally run from the symlink /usr/local/bin/lyra - as long as the goplugins and workflows are found that way, it's good.

[scottyw]

I reckon I can work with the symlink.

[thallgren]

@ahpook in some sense, I think we’re in uncharted territory with our plugin approach combined with a desire to package it all as one installable thing and that’s partly why subdirectories below bin are uncommon. It makes perfect sense to me to use a subdirectory for our use case unless we’re breaking some rule that I’m unaware of.

[thallgren]

@scottyw I don't understand the comment about "go run ...". Does using that mean that you end up with a binary that doesn't have a proper path for the executable?

[ahpook]

The rule I think is most applicable is the Linux FHS guidance:

4.4. /usr/bin : Most user commands
4.4.1. Purpose
This is the primary directory of executable commands on the system.
4.4.2. Requirements
There must be no subdirectories in /usr/bin.

The goplugins are more like the FHS description of libexec/ :

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.

[thallgren]

If subdirectories in bin is a bad idea, perhaps we should reflect that in our build? How about building:

build
├── bin
│   └── lyra
└── goplugins
    ├── example
    ├── foobernetes
    ├── identity
    └── puppet

[scottyw]

I'd be OK with those build changes @thallgren - if we're in agreement I'll make them as part of this work.

I guess we'd want to look for workflows in both of these dirs then?

EXECUTABLE_DIR/../workflows (to support brew)
EXECUTABLE_DIR/../../workflows (to support build\lyra irrespective of working dir)

Regarding your "go run" comment, my thinking is that since "go run" puts the binary in a tmp dir we can't infer the location of the workflows from the executable's location e.g.

~/github/lyra (paths ✘)✹✭ ᐅ go run -work cmd/lyra/main.go apply foobernetes --debug
WORK=/var/folders/26/7dm8dk111n1109jy0p7t0wgr0000gn/T/go-build432720005

We use the current working dir to find the goplugins in the build dir.

[thallgren]

Actually, I'd prefer if we just rooted the loader at EXECUTABLE_DIR/.. (i.e. the build dir for lyra and the root for brew) and then copied the types and workflows down there as part of the build. I also think that our original workflows should be moved down to examples and copied from there, because that's what they are. There's really no reason to let them our examples affect where the lyra binary looks for things.

I understand why we need the WORKING_DIR now. Thanks.

[scottyw]

I was hesitant to copy workflows and types because it adds a step to the workflow authoring process i.e. "edit file, run do copy via make, run lyra" whereas today we have a tighter and possibly less error-prone "edit file, run lyra" loop. If the user decides to edit the file inside the build dir to avoid the hassle of running the copy, they're at risk of accidentally losing that work when the contents are deleted/overwritten by the build.

That's really why I wanted to primarily find things based on executable location but also allow current working dir as a convenience.

[thallgren]

If the concern is the actual "make" step, then I think that we're on the wrong path. If the user wants something that's pre-built, then the brew install is the answer. If not, then the user should be prepared to issue the make command to get things in order. IMO, we should not cater for something in between. In particular, we should not make our binary expect things like that to work.

[thallgren]

Regarding authoring and extra step. If the two roots are WORKING_DIR and EXECUTABLE_DIR/.., then running the binary from the root of the lyra repository during authoring will work fine without the extra step.

[scottyw]

Yeah, you're right. So, we leave the build alone and use WORKING_DIR and EXECUTABLE_DIR/.. as the roots for finding workflows. That works for me.

[thallgren]

I think the build still needs to change so that 'bin' and 'goplugins' become adjacent.

[ahpook]

A related thing came up: when running from a container (either in operator mode or locally using docker) we needed a mount point for users to attach a volume for their workflows; I couldn't find a well established pattern for this so I just chose local - will update the README and website to match.

/src/lyra # ls -1
build
data.yaml
docs
examples
local
types
workflows

[ahpook]

I think this is complete, modulo the Type bug in #262