[Debian-med-packaging] Last step NanoPlot

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2020-04-30 11:30:42 +0200:
> Thank you for your investigation into this topic.  I have
> injected
> 
>    https://salsa.debian.org/med-team/plotly-orca
> 
> but I need to admit that I have to admit I have no idea how to build
> JavaScript packages.  Nilesh, could you lend some helping hand?
> I consider the package quite interesting in any case - so why not
> packaging it if its needed for full functionality of NanoPlot.

The last (and only) time I've been confronted to JavaScript
based programs, I had to call a professional JavaScript
developer for help.  I can review a thing or two, but fear I
won't be very helpful on that side; help is welcome indeed.

> On Wed, Apr 29, 2020 at 11:44:42PM +0200, Étienne Mollier wrote:
> > Feeding the test with alignment_fasta.bam instead of
> > alignment.bam showed that some dataset was triggering the error
> > and not others indeed.  In the next version of NanoPlot, the
> > upstream author removed the need to use the statsmodels python
> > library, which is causing the bug, so just cherry picked that:
> > 
> > 	https://github.com/wdecoster/NanoPlot/commit/da185a2e9d4f494987aedeb1eb15374cdbf99d7a
> > 
> > As long as python3-statsmodels is *not installed* on the
> > machine, it does the job.  However, if the package is pulled for
> > whatever reason, then the problem comes back.  I don't know what
> > the best approach would be to solve this properly, for the
> > moment.
> 
> May be we gain some time to work this out with upstream when
> plotly-orca is in preparation? 

I suppose both sides can be handled in parallel yes.  After
further investigations, it looks like the problem is confirmed
to be in the python3-statsmodels library:

	https://github.com/statsmodels/statsmodels/issues/6679

I pointed upstream to this issue; a few more eyes on that bug
will help hopefully.

> > On a side note, I took example on what you did for python-pauvre
> > in producing a manual page.  A long sequence of characters to
> > describe a set ended up pulling another lintian warning, so I
> > did some manual changes to relax the format of sets of options,
> > and allow well formatted manual pages.  It goes a bit against
> > the automation, will it do anyway ?
> 
> Yes.  It happens from time to time that manual changes are needed.  If
> there are really heavy changes I sometimes keep the autogenerated and
> the changes in separate manpages branch.  The idea behind it is that it
> might be possible to apply those patches to newly generated manpages.
> But in fact I did not really used this in practice.
> 
> Its your choice if you want to turn your manual changes into sed / awk /
> perl code whatever to do it automatically.  But I do not think that
> spending too much time into it.  I'm not sure how much those manpages
> are *really* used by the users.  I do not know any user of our packages
> *in person* who ever consulted a manpage.  May be that's just me but
> I would restrict the effort here to some sensible limit.

I'm personally very picky about the quality of manual pages,
I spend a lot of time reading them; but in such context it makes
sense I guess.  I will at least make sure that Lintian has no
reason to complain about their content.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier at mailoo.org>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta at home: https://boinc.bakerlab.org/rosetta/
  * Folding at home: https://foldingathome.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20200430/f3cbe3bf/attachment.sig>