15:07 <garrison> Is the fake-proc workaround described at https://github.com/sandstorm-io/sandstorm/issues/1582#issuecomment-188922691 expected to work with docker-spk? I've been unable to get it to work. (Background: I am trying to package Pluto.jl, and julia relies on /proc/self/exe for finding its sysimg at startup. If this fake-proc trick can't be made to work, I might try patching julia and rebuilding it entirely, but being able to

15:07 <garrison> start directly from the julia image on dockerhub would be nice.)

15:09 <ocdtrekkie> Since it's implemented in the pkgdef, I'd expect it to still work.

15:20 <garrison> Just realized there is a demo of this trick apparently working with docker-spk at https://github.com/zenhack/dotnet-docker-spk -- I will investigate.

15:53 <garrison> I thought that the problem might be that I had not set alwaysInclude. I added this following the example, but still no luck. /proc contains zero files in my grain.

16:11 <isd> Ack, yeah, docker-spk doesn't actually use the source map stuff -- it just packages up the contents of the container and calls it a day.

16:16 <isd> If the workaround isn't working I suspect it's a problem with the search path though; want to share your pkgdef?

16:19 <garrison> My most recent modification was to make the sourceMap and alwaysInclude identical to what is in dotnet-docker-spk, along with the same "fake" directory structure.

16:19 <garrison> (but it still does not work)

16:20 <garrison> I will clean it up and put the whole (broken) thing on github

16:34 <garrison> https://github.com/garrison/sandstorm-pluto-jl

16:37 <isd> compared to the example, you're missing oldspk in searachPath

16:38 <isd> Also you're doing the unpack/pack steps in the README?

16:39 <garrison> the dotnet-docker-spk readme? did not notice it until you pointed it out

16:43 <isd> yeah, that's important.

17:43 <garrison> I believe the readme should say "spk unpack" rather than "docker-spk unpack"

17:50 <garrison> I find it a bit mysterious that the original spk from docker-spk was 118MB but after unpacking, packing was 92MB. But the proc trick seems to work. Maybe it is using a more efficient compression on the second pass, somehow? Either that or it must be missing something ...

18:48 <isd> quite possible it's doing more efficient compression; it's using a different library. I'm not sure how wide of a difference we should expect.

18:48 <isd> There's also a cost/output size trade-off with these things, and maybe the xz lib that docker-spk is using is tunable and we could get it smaller by configuring it differently.

18:49 <isd> And yes, I think you're right that that should be spk unpack

18:49 <garrison> well, it seems to work as well as i would expect it to at this point, so I think it must be the compression

19:43 <garrison> Now that it's working on some level, it would be nice to be able to make http requests in order to install packages. I was thinking it would make sense to make a Dockerfile for powerbox-http-proxy. Thinking more, though, it might make more sense to make something to go in docker-spk/base-images; and in fact, maybe this image should just build on the existing sandstorm-http-bridge image, since it is unlikely that someone

19:43 <garrison> will use the proxy without the bridge. Thoughts?

20:00 <isd> Makes sense.

20:01 <isd> I should also update the bridge image at some point.

20:09 <isd> I wish docker had a way to do builds that weren't strictly sequential; it should be easy enough to tell which images depend on one antoher.

20:09 <isd> *another

20:21 <isd> (updated the bridge image)