pkgxdev / brewkit

build infra & `$ pkg build`
58 stars 18 forks source link

idea: {{deps.foo.bar.prefix.relative}} #116

Open jhheider opened 1 year ago

jhheider commented 1 year ago

Satisfies a very weird problem set. @ABevier is packaging podman.io, which has oddly strict requirements for where to find things:

Error: unable to start host networking: "could not find \"gvproxy\" in one of [/usr/local/opt/podman/libexec /opt/homebrew/bin /opt/homebrew/opt/podman/libexec /usr/local/bin /usr/local/libexec/podman /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman $BINDIR/../libexec/podman].  To resolve this error, set the helper_binaries_dir key in the `[engine]` section of containers.conf to the directory containing your helper binaries."

Since {{prefix}}/libexec is one of the options, one of my pitches to him is:

dependencies:
  foo.bar: ^8
build:
  script:
    - run: ln -s "../../../foo.bar/v8/bin/foobar" foobar
      working-directory: ${{prefix}}/libexec

Assuming {{prefix}} == $(tea --prefix)/podman.io/v$x, I'd expect {{deps.foo.bar.prefix.relative}} == ../../foo.bar/v$y. This is tighter coupling than I'd like, so we should (probably) discourage its usage, but it would solve issues like the above without having to alter the source code of podman. Which is the other option.

mxcl commented 1 year ago

{{tea.relative-prefix}} may be more flexible. Or both.

mxcl commented 1 year ago

the problem with the above is relative to what? I think we can assume relative the working-directory but that can change and the moustaches are static in how our mind model of them works. sorta.

Possibly this should be a tool we provide instead that can figure out relative paths

jhheider commented 1 year ago

relative to {{prefix}} was the idea. the problem is "solved" by https://github.com/teaxyz/pantry/blob/07efea28319626fb4100bc99c53c1ee31385f8e0/projects/podman.io/package.yml#L25-L47.

Basically, podman has a whitelist of places to find binary helpers, ignoring $PATH. So we add the path of the dependency's bin, relative to the {{prefix}} podman is installed under:

    # path for gvproxy to add to platform config
    GVISOR_MAJOR: |-
      $(cd "{{deps.github.com/containers/gvisor-tap-vsock.prefix}}/../\
      /v{{deps.github.com/containers/gvisor-tap-vsock.version.major}}" \
      && pwd | sed -e "s_$TEA_PREFIX/__")

Even a moustache like {{deps.foo.prefix.major}} or {{...marketing}} might be useful (the former would reduce that 3-line nightmare to a single moustache).

mxcl commented 1 year ago

k I think always relative to {{prefix}} works, though still deliberating on the name.

mxcl commented 1 year ago

I can't see a way this gets simpler since you need the major version of the dep.

I can see utility for {{relative-path-to-tea-prefix}} sorta thing. Generally, but it doesn't help a lot here due to the need for the major version of the dep.

here I think the cleanest current way to do this is:

  script:
    - run: |
        sed -i.bak -f $PROP config_{darwin,linux}.go
        rm config_{darwin,linux}.go.bak
      working-directory:
        vendor/github.com/containers/common/pkg/config
      prop: |-
        s_\(^var defaultHelperBinariesDir.*\)_\
        \1\n        "\$BINDIR/../../../github.com/containers/gvisor-tap-vsock/$GVISOR_MAJOR/bin",_
  env:
    GVISOR_MAJOR:
      v{{deps.github.com/containers/gvisor-tap-vsock.version.major}}
jhheider commented 1 year ago

yeah, my assumption was that you'd always use the major for this kind of linkage, and match the dep to that.