Re: How to run unit tests?

2020-12-12 Thread Peter Wienemann

Hi Andrey,

thanks for sharing your thoughts.

On 08.12.20 21:43, Andrey Rahmatullin wrote:

You didn't explain what actual problems do you have, but
https://github.com/lark-parser/lark/issues/792 suggests that some way you
used was skipping some of the tests?


I am not familiar enough with Python unit testing for a solid judgement 
but I find it disturbing that the outcome of the test suite depends on 
the way you run it. I wonder whether this is


a) due to a problem in the test suite,
b) due to a problem somewhere in the tested code,
c) by construction because the three different ways to run the test 
suite are not equivalent?



Upstream uses option 3 in its CI testing [2] and did not see any issues with
lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the
pybuild build system). For autopkgtest I have chosen to use option 1. The
latter two options both fail for version 0.11.1.

Which is good?


After applying a patch provided by upstream [3], also option 2 works but option 
1 still fails.

Which is good or bad? I'm not sure.


I am asking myself the same questions. That is why I am asking for 
advice here. :-)



Upstream suggested to change the way the (autopkgtest) tests are run [4].

So are you asking only about autopkgtests, not build-time tests?


Rereading it I think one should not constrain the question to 
autopkgtests but also consider build-time tests.



Is there something like a general recommendation on what is the best way
to run Python unit tests?

No (except "whatever the upstream CI runs").


This would vote for option 3:

pythonX -m tests

Best regards

Peter



How to run unit tests?

2020-12-08 Thread Peter Wienemann

Dear Python experts,

in trying to update the python-lark package [0] to the most recent 
upstream version, an interesting issue regarding unit tests showed up 
[1]. Depending on how one runs unit tests they either fail or not. Tried 
options are:


1. PYTHONWARNINGS=d pythonX -m unittest discover -v tests
2. pythonX setup.py test
3. pythonX -m tests

Upstream uses option 3 in its CI testing [2] and did not see any issues 
with lark release 0.11.1. dh_auto_test seems to use option 2 by default 
(for the pybuild build system). For autopkgtest I have chosen to use 
option 1. The latter two options both fail for version 0.11.1. After 
applying a patch provided by upstream [3], also option 2 works but 
option 1 still fails. Upstream suggested to change the way the 
(autopkgtest) tests are run [4].


I am reluctant to do this without a better understanding of the 
differences between the above three options. Can anybody shed some light 
on the differences between them? Is there something like a general 
recommendation on what is the best way to run Python unit tests?


Peter

[0] https://salsa.debian.org/python-team/packages/python-lark
[1] https://github.com/lark-parser/lark/issues/792
[2] 
https://github.com/lark-parser/lark/blob/0.11.1/.github/workflows/tests.yml#L28

[3] https://github.com/lark-parser/lark/pull/782
[4] https://github.com/lark-parser/lark/issues/792#issuecomment-739504664



Re: embedded-javascript-library usr/share/doc/python3-lmfit/html/_static/language_data.js please use sphinx

2020-08-03 Thread Peter Wienemann
Hi Frederic,

On 03.08.20 17:04, PICCA Frederic-Emmanuel wrote:
> I use sphinx, so my question is: do you know how to fix this issue

have a look at

https://bugs.debian.org/964013#35

and the following comment.

Best regards,

Peter



RFS: python-lark

2020-01-01 Thread Peter Wienemann
Dear DDs,

I prepared packaging for the parsing library python-lark (ITP bug
#941657). It is needed to bump the versions of prewikka [0] and
charliecloud [1]. The git repository is available on

https://salsa.debian.org/python-team/modules/python-lark

It would be great if someone could review the code, provide feedback and
- once everything looks fine - upload it.

Thanks, Peter

[0] https://tracker.debian.org/pkg/prewikka
[1] https://tracker.debian.org/pkg/charliecloud



Re: name change: python-lark-parser -> python-lark

2019-12-30 Thread Peter Wienemann
Hi Simon,

thanks for your helpful input.

On 30.12.19 18:04, Simon McVittie wrote:
> There are two options:
> 
> * If "lark" on PyPI is a dead project, or otherwise something that is never
>   going to be useful to package in Debian for some reason, then perhaps it's
>   safe for the lark parser to claim the python3-lark name.

The last commit happened six years ago. It might be dead but I am not sure.

> * Otherwise, if its PyPI name is lark-parser, then I would personally
>   recommend asking the upstream developer to rename the module you import
>   to lark_parser (or maybe larkparser if that's preferred), and packaging
>   it as python3-lark-parser (or python3-larkparser), optionally with
>   compatibility glue to make "import lark" continue to work (which might not
>   get packaged in Debian).

I opened a corresponding issue:

https://github.com/lark-parser/lark/issues/505

Peter



Re: name change: python-lark-parser -> python-lark

2019-12-30 Thread Peter Wienemann
Hi Thomas,

I am including the Python team to tap their expertise.

For those not familiar with the topic: We are referring to

https://github.com/lark-parser/lark

which is not in the Debian archive yet (packaging work is still ongoing).

On 29.12.19 23:10, Thomas Andrejak wrote:
> Why changing the name ? it's named lark-parser in pypi.

>From the beginning I felt uncertain how to call the source package:
python-lark-parser or python-lark.

> Moreover, in pypi, there already is a "lark" module which is not lark-parser

When filing the ITP bug I decided to choose python-lark-parser for
exactly this reason although upstream seems to call its software simply
"Lark" in most places.

Later I became aware of

https://bugs.debian.org/945823

which says:

"use the name you import in preference to the name from the PKG-INFO".

That is why I decided to change the name to python-lark. But given the
PyPI name clash this is certainly not optimal either. So this seems to
be a particular unfortunate case.

Any advice is welcome!

Peter

> Le sam. 28 déc. 2019 à 05:03, Peter Wienemann  <mailto:foss...@posteo.de>> a écrit :
> 
> Following the suggestions in
> 
> https://bugs.debian.org/945823
> 
> I have changed the name from python-lark-parser to python-lark.
> 
> The new repository URL is
> 
> https://salsa.debian.org/python-team/modules/python-lark
> 
> Peter



Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

2019-12-14 Thread Peter Wienemann
Hi Nick,

have you already found time to look into the revised packaging described
in [0] and [1]?

Cheers, Peter

[0] https://lists.debian.org/debian-python/2019/11/msg00048.html
[1] https://lists.debian.org/debian-python/2019/11/msg00106.html



Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

2019-11-24 Thread Peter Wienemann

Hi Nick,

On 11.11.19 20:01, Peter Wienemann wrote:

* d/copyright
   - the only copyright dates I can see in the source are 2014-2015


Judging from the source files, you are right. Judging from the git
commit history I see commits between 2015 and 2019. What is a better
guideline for copyright years: copyright notices in the source or the
git history? Maybe it would be best to combine both information which
would yield 2014-2019. Once I know what should be used, I will update
the copyright file accordingly.


I asked on IRC how to handle this situation. The answer was: Use the 
copyright years from the copyright notices in the source. I have just 
pushed a commit with the corresponding change to salsa.


Peter



Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

2019-11-11 Thread Peter Wienemann
Hi Nick,

thank you very much for taking the time to review the packaging and
providing such detailed and helpful feedback.

On 10.11.19 00:02, Nick Morrott wrote:
> Thank you for your work in packaging python-pyjsparser. Out of
> curiosity, what are you using to be build your package?

My primary motivation for packaging python-pyjsparser is to be able to
bump the version of Charliecloud:

https://tracker.debian.org/pkg/charliecloud

Version 0.10 of Charliecloud adds new dependencies, including
lark-parser which in turn depends on python-js2py which in turn depends
on python-pyjsparser.

> I checked out the package and built it - your work looks good, and the
> build was successful. I then ran it through lintian, Debian's package
> linting tool which you should get into the habit of using before
> uploading to salsa (and once you're a DM/DD, also before uploading to
> the archive).

I have configured my sbuild setup in such a way that it always runs
lintian after builds. But thanks to your feedback I noticed that I was
running lintian with a too high display threshold such that the only
lintian feedback I received was

"I: Lintian run was successful."

and

"Lintian: pass"

despite of the issues you discovered.

I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I
will not miss similar issues in the future.

> * d/control
>   - no Rules-Requires-Root field [lintian]

Fixed.

>   - the extended package description should probably include details
> about the library's key features/support [lintian]

Done.

> * d/copyright
>   - the only copyright dates I can see in the source are 2014-2015

Judging from the source files, you are right. Judging from the git
commit history I see commits between 2015 and 2019. What is a better
guideline for copyright years: copyright notices in the source or the
git history? Maybe it would be best to combine both information which
would yield 2014-2019. Once I know what should be used, I will update
the copyright file accordingly.

>   - you can add the Upstream-Contact field to the header

Done.

> * d/rules
>   - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1"

Added.

> * d/upstream/metadata
>   - please add and complete this file - there are plenty of examples
> in the team's salsa project [lintian]

Done.

> * d/watch
>   - +1 for asking upstream to version their releases on github

Thanks! Let's see what happens.

>   - the additional (commented) scaffolding inserted into the file by
> dh-make can be removed to leave only the version line and the URL to
> check [lintian]

The idea behind leaving the Github lines as comment was that I could
easily switch to following Github tags/releases provided that upstream
decides to publish them for future releases. But since the
"" string triggers the lintian complaint and replacing this
placeholder would be just guessing until upstream actually provides
releases on Github, I removed all comments related to this.

This also makes lintian happier. :-)

>   - as this is a version 4 watch file, we can take advantage of new
> variable substitutions for the version and extension fields, so that
> the URL to check would look like:
> 
> https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@

Very convenient variables. Changed accordingly.

> * upstream changelog
>   - there is no upstream changelog

To my knowledge upstream does not provide such a file.

> * documentation/examples
>   - There is no documentation at all, aside from the simple example in
> the README. Perhaps this snippet could be installed as an example when
> installing the package?

Done (although I am not sure whether the way I implemented it is the
recommended way to do it). Suggestions how to improve the code are welcome.

> * tests
>   - there are no tests to run at build time (and therefore no
> autopkgtests to run for continuous integration whenever the package's
> dependencies are updated). Looking at the github repo there seems to
> be a significant testsuite that should really be available in the
> Debian source package to take advantage of autopkgtest. [lintian]

The testsuite available on Github requires js2py which is not in the
Debian archive yet (thus the testsuite introduces a circular dependence:
pyjsparser <-> js2py). js2py is the next package on my to-package list
(see above).

I see two options to move forward:

1. Wait for js2py being packaged and provide autopkgtests for pyjsparser
once js2py is available.

2. Install js2py using pip for the test.

None is really nice in my opinion. Which option do you prefer?

> I hope you find this useful - if you have any questions don't hesitate
> to ask the team (the Python list is visible and archived, IRC may get
> a quicker answer...). I'm a new DD and there are likely some things
> that the more experienced members of the team will notice.

Yes, your feedback was definitely very helpful and allowed me to learn
new things.

Thanks,

Peter



RFS: python-pyjsparser (ITP bug #943785)

2019-11-01 Thread Peter Wienemann
Dear Python team,

I prepared packaging for python-pyjsparser (ITP bug #943785) on

https://salsa.debian.org/python-team/modules/python-pyjsparser

It provides a fast JavaScript parser written in Python.

It would be great if a DD could review the code, provide feedback and
(if everything looks OK) upload it.

Thanks, Peter



Joining the DPMT

2019-07-28 Thread Peter Wienemann
Hi,

I am one of the maintainers of the Charliecloud package [0]. The most
recent version of Charliecloud (0.10) has added new python dependencies
(lark [1] and its dependencies). Some of them are not yet available in
Debian.

My salsa login is wiene-guest.

I read the DPMT policy [2] and I accept it.

Peter

[0] https://tracker.debian.org/pkg/charliecloud
[1] https://github.com/lark-parser/lark
[2]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst