[Bio-packaging] testing out guix

[Ben Woodcroft]

On 20/07/15 20:04, Ricardo Wurmus wrote:
> Ben Woodcroft <b.woodcroft at uq.edu.au> writes:
>
>> And since I'm here, I notice bedtools is up to .24 on github, but .22 in
>> guix (which you wrote). There are some syntax changes though e.g. my
>> false bug report
>> https://github.com/arq5x/bedtools2/issues/257
>> What is the update procedure given there's a few tools that rely on this?
> That’s bad.  I think that a change like that a) should not be enabled by
> default, and b) deserves bumping the major version number as it’s
> breaking other tools.
>
> We could simply update the “bedtools” package and hope nothing breaks.
> When other packages depending on the bedtools command line tools (rather
> than includes or libaries) do in fact break because of this we could
> offer different versions of bedtools (though it’s hard to justify for a
> minor version).
Is another option simply to ask the authors of the downstream tools 
whether their tool uses "coverage", and if so are they aware of the 
change? That way they get to find out too and update the software 
accordingly which is goodness beyond guix, as well as less work for us. 
There's only a few I think.
> We can also just refrain from updating if we’re afraid of breaking
> things.  Instead, a user can inherit from “bedtools” and create their
> own “bedtools-bleeding-edge” package:
>
>      (define-public bedtools-bleeding-edge
>        (package (inherit bedtools)
>          (source ...) ; the new origin and hash
>          ...))
>
> Does .24 offer any substantial improvements that would justify updating
> and potentially breaking things?  Or can we just wait for future
> versions?
I'm not a big enough user of this software to be able to say from 
personal experience, though there does seem to be a number of new 
features listed on the releases page
https://github.com/arq5x/bedtools2/releases

ben