Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi Thomas, list,
On 02 Oct 2023 at 14:11:54, Thomas Goirand wrote:
> On 10/2/23 09:11, Carles Pina i Estany wrote:
> >
> > Hi,
> >
> > I've uploaded my first package (python-cloudscraper). I've filled a RFS
> > (#1053332). I have some questions (some specific to debian-python
> > organisation)
> >
> > * Question 1: Git repo
> >
> > I pushed the code to
> > https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I,
> > instead, push it already to
> > https://salsa.debian.org/python-team/packages/python-cloudscraper/ ?
>
> Yes please.
Done: https://salsa.debian.org/python-team/packages/python-cloudscraper/
(including the CI/CD setup)
> > That might be related to Question 2.
> >
> > * Question 2: debian/control, Maintainers and Uploaders
> >
> > I've read
> > https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership
> > and I think that my favourite, "long term" (does not need to be now),
> > would be:
> >
> > Maintainer: Debian Python Team <team+python@tracker.debian.org>
> > Uploader: Carles Pina i Estany <carles@pina.cat>
>
> Yes. Note that not everyone in the team agree with the Python team policy of
> having the team as Uploader, some, including myself, think that if you don't
> want other people from the team to upload, you shouldn't push the package to
> the team at all. YMMV...
Changed. I didn't want to add the team in "Maintainer:" before double
checking with the team. I will do it straight away on the next package
(python-pyaarlo, the other missing dependency of simplemonitor)
I will create a new version of the package and upload it into
mentors.debian.net when I finish this email. For reference: it will be
the version 1.2.69-3.
> > So far I've done:
> > Maintainer: Carles Pina i Estany <carles@pina.cat>
> > And no Uploader (will be the sponsor on the first time).
> >
> > Is that correct?
>
> It's probably preferable to directly put the team as Maintainer.
:-) didn't want to impose it on my first attempt before seeing the
dynamic.
> > * Question 3: allow failing tests from upstream in dh_auto_test
> >
> > Upstream has 4 failing unit tests. Besides working with upstream to fix
> > them what I've done is, in debian/rules:
> > -----
> > override_dh_auto_test:
> > # Disable tests failing from upstream
> > pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)"
> > -----
> >
> > The reason is that I don't want to disable or even ignore failing unit
> > tests in the salsa-ci pipeline. If there is a new one failing I'd like
> > to know. The override_dh_auto_test is my way of having "allowed to fail"
> > for a specific list. Is there any other, better / recommended / standard
> > way?
>
> That's very good, and that's exactly what you should do, indeed: have as
> many tests running as possible, so that you avoid regression. I would also
> strongly suggest to use autopkgtest, to avoid that someone breaks your
> package when uploading some of your dependencies.
In my first version (not published) I wrote a simple autopkgtest with an
"import cloudscraper" (I know that this is not fully testing everything
but at least something!). Then I realised that it's not needed...
without debian/tests it's just doing it:
https://salsa.debian.org/python-team/packages/python-cloudscraper/-/jobs/4762103#L180
"""
autopkgtest [22:24:36]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import cloudscraper; print(cloudscraper)" ; done
"""
I don't see this mentioned in "man autodep8":
https://manpages.debian.org/testing/autodep8/autodep8.1.en.html (should
it be there?)
But it's done this way:
https://salsa.debian.org/ci-team/autodep8/-/blob/master/support/python/generate#L78
> > * Question 4
> >
> > Any casual comments on the package would be welcomed (even in a
> > non-sponsor level). For sponsoring: the main reason of packaging this is
> > that it's an indirect dependency of "simplemonitor". Related bugs:
> >
> > RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
> > ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
> > ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113
>
> Sorry, I wont have time for this right now, but if nobody does it, feel free
> to ping me in a week or 2.
Very appreciated, I take note.
--
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat
Reply to: