For Windows, could you package and distribute the prebuilt binaries using an MSI file? (https://nsis.sourceforge.io/Main_Page)
On Fri, Nov 3, 2023 at 12:10 PM Robert Engels <reng...@ix.netcom.com> wrote: > Better to rewrite the native portions in Go. > > If you’re not going to do that, just give instructions on how to build and > let the app builder figure out how to package it. > > On Nov 3, 2023, at 1:47 PM, Jason E. Aten <j.e.a...@gmail.com> wrote: > > > It is still rough around lots of edges, but you are wanting to write your > own deployment system, you might find in https://nixos.org/ some > inspiration. > > It generalizes the idea of cryptographic hashed based dependency > management to, well, everything. > > Sadly not that easy to use; it may be harsh to inflict on end users. But > it tackles the reproducibility issue (it works on my machine! but not > yours?) head on. > You might profitably write some glue between Go and Nix that provides a > nice end user experience. > > On Friday, November 3, 2023 at 5:23:21 PM UTC Jan wrote: > >> 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/149f28a5-417e-4642-9c04-13f0254e2dcbn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/149f28a5-417e-4642-9c04-13f0254e2dcbn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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/5E033742-EDBD-4D44-BD09-60927C27448E%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/5E033742-EDBD-4D44-BD09-60927C27448E%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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/CADtPBF3dh5aSNq78aWcYFu%2BR%3DikOXpoqJWsmqhEOOFGYR0X10A%40mail.gmail.com.
