Re: Questions about including tests/ directory into package
On Fri, Mar 20, 2020 at 2:38 AM Diane Trout wrote: > The way I solved that problem in a similar package was this > > Test-Command: set -e > ; for py in $(py3versions -r 2>/dev/null) > ; do cd tests > ; echo "Testing with $py in $(pwd):" > ; http_proxy= $py -m pytest -v --pyargs > ; done > Depends: @, python3-all, python3-pytest > > The goal of autopkgtests is to test the installed package, when > autopkgtest starts running it defaults to starting in the extracted > copy of the source package. > > The goal is to make sure you test the copy in /usr/lib/python*/dist- > packages. So I assumed if cd-ed into the tests directory the package > source module wouldn't be available to the test runner. > > I did make the assumption that none of the tests messed with the python > path to look in the parent directory... Thanks, Diane. I tried with your given example, it really helped. A lot of appreciates. Thanks for your kind and deep explanation. Sincerely, Sao I Kuan saoik...@gmail.com
Joining the team and RFS
Hi, I'd like to join the Debian Python Modules Team to maintain a new python module called pysol_cards. It is a dependency of pysolfc and freecell-solver. The role of the pysol_cards module seems to be mainly to share code between those two. Packaging is ready for review and upload, please see https://salsa.debian.org/jnumm-guest/python-pysol-cards . I'd like to ask that the team create a new git repo https://salsa.debian.org/python-team/modules/python-pysol-cards for this package. I have read and agree to the team policy. My salsa account is "jnumm-guest". Cheers, Juhani Numminen
Re: Where can I find packages that need a maintainer?
Thanks, i will take a look... El 2/24/20 a las 4:24 AM, Paul Wise escribió: > On Thu, Feb 13, 2020 at 1:25 AM Pablo Mestre wrote: > >> I recently started as a maintainer of a package for Debian which is >> currently awaiting approval to be reintroduced into the repositories. [1] > In case you weren't aware, there are some extra steps when > reintroducing packages: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs > > Principally this is about reopening bugs closed by the removal and > then triaging them and closing any fixed in the new version. > > https://www.debian.org/Bugs/Developer#closing > > Last time I needed to do this, I ran this hacky shell one-liner: > > bts $(for bug in $(curl > 'https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=colortest-python' > | pandoc -f html -t plain --wrap none | grep -B1 -F +rm | grep -o > \#[0-9]\\+ | tr -d \#) ; do echo -n "unarchive $bug , reopen $bug , "; > done) > > For your package it gives this command: > > bts unarchive 753281 , reopen 753281 , unarchive 936320 , reopen > 936320 , unarchive 782208 , reopen 782208 , unarchive 890074 , reopen > 890074 , > > See-also this request for making it easier to do this: > > https://bugs.debian.org/949125 >
Re: Questions about including tests/ directory into package
On 3/19/20 7:22 AM, Sao I Kuan wrote:
> Hi,
>
> I'm newcomer to Debian packaging, and trying to add the autopkgtest
> test script into python-tinyalign[1].
>
> [1] https://salsa.debian.org/med-team/python-tinyalign
>
> And now I'm facing a (maybe simple) problem.
>
> The upstream test files are located in tests/ directory, but seems
> this directory is excluded during packaging.
> I have no idea how to include this tests/ directory.
>
> 1. Please let me know is there any variable for including the specific
> file/directory.
> 2. Why and when the tests/ directory excluded? I tried to find the
> logic in dh-python [2], but failed.
>
> [2] https://salsa.debian.org/python-team/tools/dh-python
>
> 3. Is this a correct approach for including the excluded test materials?
>
> Always appreciates.
>
> Sincerely,
>
> Sao I Kuan
> saoik...@gmail.com
Hi,
Ah... how much I hate python and setuptools for being so liberal and let
every developer design its own thing... we end up with no standard, one
having to read setup.py, know all the internals of setuptools, and this
thread is one more collateral of that. :/
For this specific package, what's being packaged is what's found by
setup.py. In that file, you can see:
packages=find_packages("src"),
Setuptools will only find "tinyalign" under the "src" folder, as a
python module to package, which is why that's the only thing that is
going to be packaged.
IMO, the best approach to this problem is to convince upstream to move
their tests folder into the Python package folder. Best is even to make
upstream get rid of the "src" folder, rename that one "tinyalign" and
put the tests folder in it. In other words, make upstream do:
mv src/tinyalign .
rmdir src
mv tests tinyalign
sed -i 's/packages=.*/packages=["tinyalign"],/' setup.py
Cheers,
Thomas Goirand (zigo)
Re: Questions about including tests/ directory into package
> packages=find_packages("src"),
>
> Setuptools will only find "tinyalign" under the "src" folder, as a
> python module to package, which is why that's the only thing that is
> going to be packaged.
>
> IMO, the best approach to this problem is to convince upstream to move
> their tests folder into the Python package folder. Best is even to make
> upstream get rid of the "src" folder, rename that one "tinyalign" and
> put the tests folder in it. In other words, make upstream do:
that's not correct: the "src" directory is a very well know
best-practice (you can google for it, if you need references),
intended to avoid situations where "import mymodule" will have
inconsistent results depending on where you run that command and easy
of testing.
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until end...)
Hi, python-fixture (the binary) is gone, therefore we have #952130 and #952127. I've been reluctant to remove Py2 support from these, because unittest2 needs it, and this would break a lot of packages (including, indirectly, stuff like sphinx, pytest, etc.). What is it that the team suggests at this point? Should I reintroduce Py2 support in fixtures, or should we go ahead and do a missive Py2 RM of what's left in the archive? We're down to only 366 packages with Py2 in testing. We can either postpone forever, or just go hardly on it (but there will be inevitable collaterals...). Your thoughts? Cheers, Thomas Goirand (zigo)
Re: When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until end...)
> python-fixture (the binary) is gone, therefore we have #952130 and > #952127. I've been reluctant to remove Py2 support from these, because > unittest2 needs it, and this would break a lot of packages (including, > indirectly, stuff like sphinx, pytest, etc.). you can remove them when http://sandrotosi.me/debian/py2removal/python-traceback2_1.svg http://sandrotosi.me/debian/py2removal/python-linecache2_1.svg show no nodes with a red border. > What is it that the team suggests at this point? Should I reintroduce > Py2 support in fixtures yes, it should have not been dropped since it still had reverse dependencies. > or should we go ahead and do a missive Py2 RM > of what's left in the archive? that's just too much breakage. > We're down to only 366 packages with Py2 in testing. We can either > postpone forever, or just go hardly on it (but there will be inevitable > collaterals...). bullseye freeze is 9 months away (https://lists.debian.org/debian-devel-announce/2020/03/msg2.html) so it's not acceptable to break reverse dependencies recklessly at this time. let's take the slow and careful road, and work from leaf packages backwards, as it has happened since now. we can re-evaluate when we're closer to the freeze. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Where can I find packages that need a maintainer?
On Thu, Feb 13, 2020 at 1:25 AM Pablo Mestre wrote: > With the desire to continue contributing I would like to know where I > can find other packages that need a maintainer. The WNPP data (specifically RFA, O bugs) list packages needing a new maintainer: https://www.debian.org/devel/wnpp/ There are several options for querying this data: Install and run the how-can-i-help package: https://wiki.debian.org/how-can-i-help Use the wnpp-check/wnpp-alert scripts: https://manpages.debian.org/wnpp-check https://manpages.debian.org/wnpp-alert Use one of the websites that presents the WNPP data in different ways: https://wnpp.debian.net/ https://wnpp-by-tags.debian.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Autopkgtest issues blocking python3.8 as default transition
I've gone through and statused the issues currently listed on the package tracker for python3-defaults migration that are autopkgtest related [1]. I stuffed it into a pastebin [2]. I'm open to suggestions about where better to maintain such a list. If you ever want python3.8 as default python3, please have a look and fix stuff. The ones labled py3versions -i are likely related to a common error I wrote to on debian-devel recently [3]. They are easy to fix. If you update this, please also update /topic in #debian-python as it is listed there also. This was painful to do. I'm unlikely to do it again (things like this are one of the reason I no longer co-maintain python3- defualts). It'll make everyone's life easier if we document our progress and don't stumble over each other. Scott K [1] https://tracker.debian.org/pkg/python3-defaults [2] http://paste.debian.net/1135796/ [3] https://lists.debian.org/debian-devel/2020/03/msg00280.html signature.asc Description: This is a digitally signed message part.
