That's right, such a scheme would definitely work. The benefit of that scheme would be to avoid downloading from npm, which would keep the repository more self-contained.
Downsides that come to mind: - It will require asking users to install git-lfs separately. - Would require developing a bundled installation script in Emscripten that non-emsdk users are asked to run to uncompress. (comparable and does not avoid a npm install) - For npm developers, running npm install is already familiar and idiomatic, but a custom script is, custom. - There may be need to ship platform-specific versions of some npm tools (closure-compiler-win.zip, closure-compiler-macos.zip, closure-compiler-linux.zip, closure-compiler-arm.zip), or create fat zips that have all platforms. For closure specifically there is a JS version, to could use just that instead. - More maintenance work compared to the npm approach (e.g. on packaging and versioning) - Migrating between versions becomes harder for users. With npm if user wants to try to update to latest closure that the Emscripten tree does not currently have, they can edit a single line in package.json and reissue npm install. With a custom zip users would have to figure out the directory structure and the install/update mechanism that the custom scheme uses to replace the tool with a new installation. Though there is no reason why such a "zip in the repository" approach (or migrating distribution to emsdk) could not be adopted also later. I think avoiding npm up front for the fear of it possibly being unreliable is probably not sensible. Since npm is the least work to use and maintain, I would recommend seeing that path out until it fails, and then migrating to some other heavier method if npm is not feasible. to 19. jouluk. 2019 klo 9.19 Shachar Langbeheim ([email protected]) kirjoitti: > > You can use Git LFS and commit zipped directories, and then during the emsdk > installation process unzip them. > > On Wed, 18 Dec 2019 at 22:04, Jukka Jylänki <[email protected]> wrote: >> >> ke 18. jouluk. 2019 klo 9.27 Gabriel Cuvillier >> ([email protected]) kirjoitti: >> > >> > My two cents on this, from the point of view of a daily Emscripten user on >> > various projects : >> > >> > If this change does not impact end-users of Emscripten, that just want to >> > do C++ development targeting WebAssembly, then this is perfectly fine. >> > This change would just be an EMSDK "implementation detail", and I agree >> > that from this point of view, removing the Java dependency is interesting. >> >> For emsdk users this is indeed just an implementation detail, as emsdk >> install still sets up the SDK functionally like it used to. >> >> > An alternative suggestion: instead of having to rely on 3rd party >> > distribution system, why not "precompile/bundle" closure (as well as >> > minify-html, or any other 3rd party dep), and use a more classic >> > CDN-approach to deliver these big files. >> >> The reason for this is point #1 from the first post, and was discussed >> in https://github.com/emscripten-core/emsdk/pull/404#issuecomment-564720935, >> basically each update of closure would increase the size of the git >> repository by ~30MB/+13% overall download size. And since git tracks >> all history, that means it will download all old versions when one git >> clones. After a couple of updates of Closure, the size of all the >> Closures in the tree history would be a larger portion of the overall >> Emscripten git repository than Emscripten bits itself. >> >> Git LFS route would work for this only if Closure and html-minifier >> and other tools would provide a single file amalgamation of the whole >> toolchain they provide, but unfortunately this is not the case. >> Closure and html-minifier are split across hundreds of small files, so >> Git LFS cannot be applied. >> >> > This would remove the need for a package management system (npm, or even >> > PIP if you have the same idea for Python tools) running on users >> > machine... and potentially breaking for various reasons (network failures, >> > misconfiguration of PATH, weird interaction with system-wide installation >> > of Node/npm, etc..) >> >> Only if Git LFS was feasible to avoid repository size bloat. Otherwise >> it would mean developing and maintaining support into Emsdk + its CDN >> backend to serve Closure and html-minifier etc. (which using npm helps >> avoid, points #2 and #4) >> >> Emsdk does provide a fixed version of Node.js for all platforms, so >> system-wide installations of Node/npm, and also PATH configuration, >> should not matter here. Network failures are a possibility, but that >> may be a bit of a FUD point - the robustness and reliability of npm >> infrastructure is likely better maintained compared to the robustness >> of emsdk infra. (there are probably 100x more active users of npm >> ecosystem compared to emsdk ecosystem) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-2kMqBLJ%3D-3zjRFGTYM8yLOZOFx4ALhXrudWtXu-HyXNQ%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CA%2B_KjGZxDc1YTSPjL-qCTZig13xf_pazZRO5KBAjH8x%3Dt1%3Dquw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-2dhH_tAejNqLn07C-iwhnFPGk-s8p-pe3%2BdW_gwoxr_A%40mail.gmail.com.
