IRC channel logs


back to list of logs

<rekado>what are your thoughts on using something like for JavaScript “sources”?
<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.
<PurpleSym>That link is 404 for me, rekado.
<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 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>Technically speaking there’s an upstream build bundled with the Python library here:
<PurpleSym>There’s no pre-built `bokeh.js` on for this version though.
<PurpleSym>Hashes for bokeh.js are the same from and pypi, so it should be fine to use either.
<rekado>when the “build” directory on 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 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.
<PurpleSym>It’s look like this:
<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.
<PurpleSym>Hiding them is not an option?
<PurpleSym>(guix-science has r-diagrammer, btw:
<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>it should at least be an origin
<rekado>I’m admittedly not convinced that our usual package tools are worth using for these huge JavaScript environments.
<zimoun>rekado: «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
<zimoun>of tools». :-)
<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. :-)
<zimoun>French reader,
<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>I did like $, though
<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>do you use reticulate?
<zimoun>no, I did know what it was. )-:
<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.)
<zimoun>rekado, and about perfomances?
<rekado>don’t know
<zimoun>rekado, I have never tried but once I see that
<rekado>ah, with quasiquotes
<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>rekado: In practise it’s true that JavaScript environments are – just like crates right now – just sources waiting to be processed. But having individual packages is valuable for web development and precisely what I’m doing right now (
<PurpleSym>During development I just use `guix shell -D bawwab`.