GNU bug report logs - #53402
Add python-mne

Previous Next

Full log

View this message in rfc822 format

From: Vinicius Monego <monego <at> posteo.net>
To: Vivien <vivien <at> planete-kraus.eu>, 53402 <at> debbugs.gnu.org
Subject: [bug#53402] Rebase it for the new python packages
Date: Sun, 06 Feb 2022 20:06:38 +0000

Em dom, 2022-02-06 às 15:49 +0100, Vivien escreveu:
> Hello, thank you for your review!
> 

Thanks for the v4.

[...]

> 
> > As a rule of thumb for Python packages with tests in Pytest, the
> > check
> > phase is overriden and Pytest is called manually. When the tests
> > are
> > in
> > a subfolder inside the module, add a --pyargs <package> parameter
> > to
> > the pytest command, see e.g. the python-cartopy package. I could
> > run
> > the python-nibabel tests with this change without having to delete
> > anything.
> 
> OK.

I noticed that some of the tests aren't running, like in flake8-array-
spacing. If the check phase ends with "Ran 0 tests" then the tests are
not being collected.

If there are no tests to be collected, the package should have a
#:tests? #f along with a comment saying that there are no tests. If
there are tests to run, the check phase will have to be overriden to
run them.

For imageio-ffmpeg there are tests in github but not PyPI. I tried to
source from github but most tests require online data. In that case
#:tests? #f should be added with an explanation.

> 
> > If the tests still can't run because of missing data, it's fine to
> > source from the upstream repository instead of PyPI, or skip the
> > few
> > tests that need them or at all if the repository doesn't ship a
> > setup.py. If tests are to be disabled, they should also have a
> > comment
> > with the reason.
> 
> For MNE, the test data set is a separate repository without a
> license,
> so I disabled the tests.
> 

OK. I tried to download the test dataset from within the mne module and
they don't have a license agreement or anything, while to download
individiual datasets the user has to agree to the (non-free) terms. I
wonder if that's acceptable for merging in Guix?

In [1] I found that there are more base dependencies that aren't listed
in the pypi importer. They should be added to propagated-inputs. If
tests can't run, then native-inputs can be removed.

> > The 'test-less' packages shouldn't be needed AFAICS. Tests should
> > run
> > by overriding the check phase as stated above (untested).
> 
> The test-less packages are part of a dependency cycle; decopatch
> requires them for the tests to run, and they require decopatch or
> each
> other too. If I disable all tests (pytest-* and decopatch) it would
> work, but I’m not sure I should do that.
> 

OK, it seems that they have a web of dependencies on each other. This
is the first time I see such a case.

Usually, pytest modules should go into python-check.scm, not python-
xyz.scm.

> > I also have a few comments about the patches in general:
> > 
> > > +    (source (origin
> > > +              (method url-fetch)
> > > +              (uri (pypi-uri "imageio-ffmpeg" version))
> > > +              (sha256
> > > +               (base32
> > > +               
> > > "0ff14079izsyxwf6ki68k9a7w5krjlal7lwqvzg2bbddl92l5spj"))))
> > 
> > Could you style it as
> > 
> >     (source
> >      (origin
> >        (method url-fetch)
> >        (uri (pypi-uri "imageio-ffmpeg" version))
> >        (sha256
> >         (base32
> > "0ff14079izsyxwf6ki68k9a7w5krjlal7lwqvzg2bbddl92l5spj"))))
> > 
> > and the other packages too?
> 
> OK.
> 

The base32 line was truncated in the mail, the hash should be in the
same line of 'base32'. But I can fix that.

[...]

> 
> > 
> > Some of the descriptions are not full sentences (e.g. in python-
> > pytest-
> > harvest-minimal). Please check that descriptions are full
> > sentences.
> 
> I’m not sure I understand. I reworked some descriptions, but didn’t
> find non-full sentences. Could you explain what you mean?
> 

Full sentences are made of a subject + predicate. This one:

+    (description "I/O support for EEGLAB files in Python.")

doesn't have a subject.

Usually the subject in the description is the package's name itself or
"This package...". e.g. "EEGLABIO is a library..." or "This package
provides I/O support..."

Something else to avoid in descriptions is marketing talk, such as
'simple and reliable' in python-imageio-ffmpeg.

[...]

The package modules you changed are also missing your copyright line.

Vinicius

[1]
https://github.com/mne-tools/mne-python/blob/main/requirements_base.txt

> 
> 
> Sure!
> 
> Best regards,
> 
> Vivien

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.