chore: try embed trick to include non-go files on vendor

[markphelps]

try to fix: #558

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.48%. Comparing base (52fec14) to head (c58bc43).
Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #559   +/-   ##
=======================================
  Coverage   85.48%   85.48%           
=======================================
  Files           8        8           
  Lines        3933     3933           
=======================================
  Hits         3362     3362           
  Misses        571      571           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nhunam]

LGTM

[GeorgeMac]

Nice hack. Do we need to do the same for the other non go files?

seems like we will run into this with the dynamic libs too?

Shame we have to then also add all these objects to any resulting binaries in another location in memory for everyone just to make this work 😮‍💨

[erka]

this doesn't work :(

ext.go should be in evaluation package with

package evaluation 

import "embed"

//go:embed ext/*
var _ embed.FS

[markphelps]

this doesn't work :(

ext.go should be in evaluation package with

package evaluation 

import "embed"

//go:embed ext/*
var _ embed.FS

is this because we need to fake embed the libraries too for vendoring? i hope this doesn't make the filesize double in the archive

[erka]

@markphelps I tried the local app with vendor vs shared deps and the binary size was the same. It would be nice to have a deeper knowledge about this situation.

[markphelps]

So this is interesting.. it now packages both libc folders in /ext and includes them in the archive:

This might actually allow us to implement what is asked for in #141 (comment) by using buildtags to for the appropriate arch. It still would mean that the initial go get would be like 30mb transfered though, but it would only include the needed lib in the actual build of the consuming binary

[markphelps]

also its just plain wrong as the musl folder is missing the linux subfolders.. something is off with the packaging workflow now

[markphelps]

ok so i removed the ext.go embed and published a new release and can verify the packaging issue is not related to the ext.go change, there is something else wrong with our packaging workflow that I'll need to fix first