That works if what I'm doing is a end product (a server or something). But what I'm doing is in itself a library. Imagine if every library offers a docker/VM image, how is the end-user supposed to merge those docker images ? The docker is also not a viable/ergonomic solution in my case. I mean ... actually I do offer a docker for one of my projects <https://hub.docker.com/r/janpfeifer/gomlx_jupyterlab>, along with Jupyter, a Tutorial and demo. But generically, it is a library, and I would like it to be easily `go get`able. Or at most with one simple/standard step.
Yes, I hear you with respect to unnecessary extra dependencies (X11) -- at least make them optional, right ? But In my case the dependencies are essential, and the docker doesn't really solve the problem... But also I'm running out of hope that there would be anything to solve it, I'm almost thinking I should write something myself. On Thursday, November 2, 2023 at 11:54:01 PM UTC+1 Jason E. Aten wrote: > What I would do for that case would be to deliver the users a either a VM > image (heavy), or a docker container (lighter) with batteries included > inside. > > There is often little need to write a docker file unless you really want. > Just get everything working inside docker and "docker commit" it to an > image. I do this often for projects that need python/R + 100s of > libraries. Its really the only sane way to deliver sprawling dependencies > that assume they can write all over the filesystem. > > One hint: I recently did this for code that wanted to output graphics, and > that needed X11 (or Xvfb), and that wanted systemd, which is available in > docker but used to be discouraged so is not available in many base images. > So I would recommend starting an docker image that already supports systemd > and X11, if graphics (or x11vnc, say) is ever going to be desired. Its a > pain to add after the fact. Podman claims to be useful for this, but I > found in immature and not really production ready when trying to run it on > blah standard Ubuntu 22. > > On Wednesday, November 1, 2023 at 9:08:51 PM UTC Jan wrote: > >> Thanks @Jason, but the point was exactly not need to do anything extra: >> no manual unzipping of a file, or manual Makefile/Magefile. >> >> Let's say project in Go links some 30 external modules, 5 of them have >> their own specific steps that need to be read, understood and and run to >> install them ... very quickly the user just gives up from >> installing/compiling the thing, with good reason ... >> >> The Go toolset solves that beautifully for Go only projects. But at least >> in my line of work, that's not feasible, I need to interface with libraries >> that in turn require other libraries in C++ (OpenXLA/llvm for JIT), Rust >> (HuggingFace Tokenizer), C (Gtk), etc. >> >> cheers >> >> >> >> >> On Monday, October 30, 2023 at 7:42:19 PM UTC+1 Jason E. Aten wrote: >> >>> > including the `.a` (static libraries) in the Github just got to its >>> limit (100Mb) >>> >>> I have used bzip2 to compress libraries that are too big for Github. If >>> that gets them under the limit, then great. >>> Just provide installation instructions or a Makefile target that >>> decompresses them once checked out. >>> >>> (Or xz? Apparently it can compress more than bzip2; but I have no >>> experience with it. https://en.wikipedia.org/wiki/XZ_Utils ) >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/58a7156a-94e8-4084-b82a-a7269d785089n%40googlegroups.com.
