IRC channel logs
2022-11-04.log
back to list of logs
<rekado_>zimoun: the r-torch update takes a long time to build… Have to build pytorch 1.12.1 because that’s what the new version of liblantern wants. <rekado_>still waiting for it to finish building. <zimoun>an issue on hpc.guix.info/browse? It returns «The package is gone!» for many packages. <rekado>I had the same problem on guix.mdc-berlin.de many times before. <rekado>ACTION prepares to push the CRAN commits straight to the master branch <rekado>zimoun: the CRAN updates are out, you’re welcome to start work on the bioconductor update <rekado>let me know if you need help with it <zimoun>rekado: cool! Thanks. I am going to start and report here this day about my progress. <rekado>zimoun: FYI: I’m applying a few forgotten patches for R packages. <abrenon>should've come here directly instead of bothering the main chan, sorry <abrenon>so I was trying my first workflow, and quickly felt the need to pass the root directory of where everything I study is located <abrenon>I read about the -i option to run and thought that was what I needed, but I can't seem to make it work despite all the nice help from rekado <abrenon>more than my particular problem at this moment, I think this deserves more space in the documentation <abrenon>only prompts more questions than it answers <abrenon>and reading this documentation, I cannot help but long for a glimpse at this promising analysis.w file <rekado>abrenon: yes, the manual is a little too terse here, I agree <rekado>abrenon: previously we discussed the addition of a working directory where the workflow should be executed (and thus all relative file names should be resolved from) <abrenon>which would cover the particular need I wanted to use --input for <abrenon>but not the need for the newcomer to guess the syntax for free inputs inside workflow files <rekado>abrenon: I’m not sure I fully understand your use case just yet <rekado>if your workflow’s processes declare an input file ABC.txt and there’s no ABC.txt generated by any of the other processes and there is no ABC.txt in the current directory then ABC.txt is a free input <abrenon>well just what you said but expressed more clumsily <rekado>in that case you can do --input=ABC.txt=/path/to/my/ABC.txt <rekado>obviously this is tedious for more than a handful of inputs. <abrenon>ohhh, I thought the argument to file in the input field was a string <abrenon>I would never have guessed that this could act as a variable name and be overridden <abrenon>which is why I was still trying with an undefined {{corpus_root}} and hoping -i corpus_root=/… would do the trick <abrenon>but yeah, since my input (and output) files for that matter share a common path prefix, I wanted to pass this as a variable named "corpus_root" <rekado>I’m not really happy with this file-centric way of dealing with process connections and workflow inputs, so I’d be happy if we could change this in the long term. <abrenon>and was trying to string-append my way into getting the input file values right <rekado>but for this particular issue I suppose it would be enough to show the workflow to augment the example <rekado>we have “file”, which is meant to be a nicer “string-append” <abrenon>because from a newcomer's perspective, it is not obvious <abrenon>and I know that finding non-obvious parts of a documentation when you have designed something can be tricky because you know everything inside-out <abrenon>which is why I came in the first place <zimoun>rekado: I agree that connecting via files does not seem optimal. On the oher hand, it is really practical (intermediate save point, ease detecttion about what need to be recomputed, etc.). Well, I do not know what could be better to declare the DAG. <zimoun>rekado: I have not finished the Bioconductor upgrade. Quick question: why the updater does not apply the recommandation as add/remove inputs? <rekado>zimoun: we have no way of telling the updater that its recommendations are wrong <rekado>there are many such cases where we know better <rekado>r-xfun shouldn’t have r-knitr as a native-input because that would lead to a cycle <rekado>some packages have inputs that are needed for building vignettes; these inputs cannot easily be derived <rekado>the importer sometimes recommends moving a package from propagated-inputs to inputs, but we know better <rekado>it also doesn’t know what to do about all these js-* native-inputs <rekado>it’s a lot of work to automate this; it would be less work to support some kind of property that would allow us to override recommendations <zimoun>I see. Somehow it is a question of fixing updater errors. It could be interesting to know the ratio between wrong recommandations vs correct ones. <civodul>the guix-cran channel suggests that the importer does a good job though, no? <zimoun>I agree that some property would help. The question is also the work to maintain these properties vs the manual tweaks at each release. <rekado>the guix-cran channel doesn’t do anything about bundled minified JS <rekado>we could add a special case for these kinds of packages, of course <rekado>but the problem is larger than that. <civodul>but you were mention cycles above with r-xfun and r-knitr <rekado>yes, this keeps happening on updates <rekado>so in the past I added commented (native-inputs (list r-knitr)) to packages to warn future rekado about this