Command to query “Python versions that are installed *with* standard library”
Howdy all, What is a ‘py3versions’ (or alternative) command that can be run in AutoPkgTest, to query the Python versions that are installed on this machine *with* their standard library? The ‘pythonX.Y-minimal’ packages can be installed *without* standard library, but will still appear in the ‘py3versions --installed’ output. This means it's possible to have an AutoPkgTest test that attempts to run a module for all the ‘py3versions --installed’ versions, then fail because an import of a standard library module fails. What command, hopefully as simple as ‘py3versions --installed’, can be used in AutoPkgTest to interrogate *only* those Python versions on the local machine that have their standard library installed? -- \ “Friendship is born at that moment when one person says to | `\another, ‘What! You too? I thought I was the only one!’” —C.S. | _o__)Lewis | Ben Finney
Re: Build test failure for python-easydev
On Wed, Jan 23, 2019 at 09:58:45AM +, Nick Morrott wrote: > > Cool. Thanks a lot. Your outright contribution was very helpful and > > really welcome. The only change I made is to revert your commit > > 38022ac5 since there is no point in changing the upstream source that > > way. I agree upstream should not ship that file but if its in the > > upstream tarball I see no need to remove it here. > > Apologies about that. No problem. :-) > My build failed immediately due to the presence > of that file when I started testing, and removing it got the build to > proceed so I could look at the test failures. > > That file is not present in their upstream github repository at the > release date of 0.9.37. pypi points to the repo as the definitive > source location so it's my fault for not investigating the pypi > tarball further. Strange. I have no idea how this file might have sneaked in. It might be that PyPI changed the content of the file without renaming it? I used what I once obtained and stored in pristine-tar. May be you did not used `gbp buildpackage` - thus the difference. > If it persists it can obviously always be removed > automatically via d/copyright if desired. It never harmed my build. I tend to not touch the original tarball via d/copyright to keep the md5sum equally to the download - which does not seem to be the case any more if you are right (I did not mind to check admittedly). I guess it will "heal" for the next version and I have more important things than this on my desk now. > > Definitely. Package is uploaded - one worry less. :-) > > Excellent! Thanks again Andreas. -- http://fam-tille.de
Re: Build test failure for python-easydev
On Wed, 23 Jan 2019 at 06:54, Andreas Tille wrote: > > Hi Nick, > > On Tue, Jan 22, 2019 at 11:33:09PM +, Nick Morrott wrote: > > > I'm a newcomer to the python team, but I'm looking at this at the > > > moment to improve by debugging and python packaging. > > Cool. Thanks a lot. Your outright contribution was very helpful and > really welcome. The only change I made is to revert your commit > 38022ac5 since there is no point in changing the upstream source that > way. I agree upstream should not ship that file but if its in the > upstream tarball I see no need to remove it here. Apologies about that. My build failed immediately due to the presence of that file when I started testing, and removing it got the build to proceed so I could look at the test failures. That file is not present in their upstream github repository at the release date of 0.9.37. pypi points to the repo as the definitive source location so it's my fault for not investigating the pypi tarball further. If it persists it can obviously always be removed automatically via d/copyright if desired. > > Hope this helps, > > Definitely. Package is uploaded - one worry less. :-) Excellent! Cheers, Nick
