IRC channel logs
2021-11-30.log
back to list of logs
<rekado>there’s a “build” directory containing JS pre minification. <rekado>it’s not really source code, but it’s probably the best we can get to at least do the minification by ourselves. <rekado>this really is a build output, of course. <rekado>guess I missed the trailing slash <rekado>morally speaking it’s not source code; but practically speaking: I’ll take it. <PurpleSym>Hm, I wouldn’t ask whether it’s minified or not. In the end it does not matter because both deny the right to modify. Instead I would ask whether the source can be trusted. So can we trust unpkg.com? Is there any upstream-provided build? <rekado>there is no upstream-provided build <rekado>I think that concatenated JavaScript does not deny the right to modify <rekado>it’s not the preferred format, because it’s not the source language <rekado>(that would be typescript in many little files) <rekado>but it’s editable in a way that enables modifications easily. <PurpleSym>There’s no pre-built `bokeh.js` on npmjs.com for this version though. <PurpleSym>Hashes for bokeh.js are the same from unpkg.com and pypi, so it should be fine to use either. <rekado>when the “build” directory on unpkg.com is really the output of some npm command, I wonder if we should just run this by ourselves in a well-defined Guix environment and store the resulting concatenated js files. <rekado>I mentioned unpkg.com not for bokehjs in particular but for the general problem of missing source code. <rekado>I first came across unpkg when I looked for unminified source code of vis-network.js, which is needed for r-diagrammer. <PurpleSym>We could go one step further and use the `npm-binary` importer to create “packages” for all dependencies too. <rekado>yes, I just wonder if we should have hundreds of packages each, or somehow combine this all into one package. <rekado>it’s not like we’re actually going to reuse existing js packages for the most part. <PurpleSym>Sure, reuse will be minimal for most libraries and for web usage we’ll bundle them up anyway, but having one package per NPM package alleviates automation. <PurpleSym>Most of these packages I have not even touched. It’s just `guix import npm-binary -r <foobar> > file.scm` – and that’s it. <rekado>it results in a lot of low quality packages, so maybe we could modify the importer to build one big package with lots of inputs. <rekado>this way we wouldn’t need to bother with descriptions and synopses and home pages of each and every god-forsaken JS file. <rekado>yes, I’ve seen r-diagrammer there. <rekado>my quest for a from-source build of r-diagrammer is a bit older than that :) <rekado>hiding them from the UI doesn’t hide them from our text editors :) <rekado>if we don’t care about description and synopsis enough to make them pretty then maybe we shouldn’t record them in the first place. <rekado>perhaps we could have a different DSL for these pesky npm imports <rekado>something that in source form we don’t have to be ashamed of :) <rekado>HN: Will Nix overtake Docker? Top comment: Oh god I hope not. <PurpleSym>Can we have `guix graph`, `--with-inputs` and all the other tools Guix provides with a different/custom DSL? Would it return a package? <rekado>I’m admittedly not convinced that our usual package tools are worth using for these huge JavaScript environments. <zimoun>rekado: https://blog.replit.com/nix-vs-docker «Reproducible Environment with Docker» where ’FROM node:12-alpine’ ’RUN apk add --no-cache python g++ make’ ’RUN yarn install --production’. Ahah! Author of the post is probably missing their own sentence: «Reproducible environments are useful to ensure all developers on a project have the exact same set <rekado>I see that ’guix graph’ could be impressive, but personally I don’t see much value in treating these environments as a collection of packages. I see the JS part as a complex collection of source files that need to be built together. <rekado>zimoun: if they all live in the moment and run the command at the same time there’s a good chance they’ll get the same tools. <zimoun>Pre-last paragraph explains, it is indeed not really reproducible and breakage are around. ;-) <zimoun>rekado, BTW thanks for the HN thread. Some comments are interesting on how Nix is perceived. :-) <rekado>I have to admit to being terribly superficial, but I can’t help myself: {} ${} <> []; — but () is problematic syntax, amirite? <zimoun>heh! Not problematic “foo $ bar >>= baz <*> bong” but ’(foo (bar (baz (bong))))’ is. Cognitive mysterious ?! <rekado>yeah, Haskell syntax is certainly … special <rekado>I never liked it, even when I was a big Haskell fan <rekado>R is similarly ugly when it comes to custom infix operators. <zimoun>I am still a big Haskell fan. And the issue with the syntax is you need permanent practise. Otherwise, ouch. <zimoun>R is so ugly that I try to avoid at all cost… but I can’t. Damned Bioconductor! :-) <rekado>This package provides an interface from R to Python modules, classes, and functions. When calling into Python, R data types are automatically converted to their equivalent <rekado>+ Python types. When values are returned from Python to R they are converted back to R types. <rekado>but perhaps that’s the wrong way around. How about python-rpy2? <rekado>(I’m not advocating for the use of Python just to avoid using R directly.) <rekado>I remember some people really didn’t like them and called them a betrayal of Haskell’s values… <zimoun>arf, maybe. But it is so easy to have something silently wrong with R. Too much DWIM, IMHO. <rekado>QQ allows you to glue anything together, even if it doesn’t type checks. <zimoun>No! So you have the inconvienent of both worlds ? <zimoun>I mean «no» because I am really surprised :-) <PurpleSym>During development I just use `guix shell -D bawwab`.