[pacman-dev] python-2.7 and pacman test-suite
Just a heads up that the test-suite does not enjoy python-2.7... Total = 200 Pass = 82 ( 41.00%) Expected Fail = 6 ( 3.00%) Unexpected Pass = 2 ( 1.00%) Fail = 110 ( 55.00%) Although, we do get two bug fixes for free! Allan
Allan McRae
Just a heads up that the test-suite does not enjoy python-2.7...
Total = 200 Pass = 82 ( 41.00%) Expected Fail = 6 ( 3.00%) Unexpected Pass = 2 ( 1.00%) Fail = 110 ( 55.00%)
Although, we do get two bug fixes for free!
Allan
If I'm diagnosing correctly, with python 2.6, the generated package files contain a ".PKGINFO" file, while python2.7 creates packages containing a file "./.PKGINFO" and libalpm complains saying the package is malformed. -- Rémy
On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng
Allan McRae
wrote: Just a heads up that the test-suite does not enjoy python-2.7...
Total = 200 Pass = 82 ( 41.00%) Expected Fail = 6 ( 3.00%) Unexpected Pass = 2 ( 1.00%) Fail = 110 ( 55.00%)
Although, we do get two bug fixes for free!
Allan
If I'm diagnosing correctly, with python 2.6, the generated package files contain a ".PKGINFO" file, while python2.7 creates packages containing a file "./.PKGINFO" and libalpm complains saying the package is malformed.
Looking quickly at the code here, I'm a bit surprised how we do it. The behavior of os.walk() might have changed in what it is returning? Patches are more than welcome to fix this brokenness and maybe some other things: 1. Do we really need to gzip? 2. Why are we making real files first at all; couldn't we go completely in memory to create these test packages? -Dan
Dan McGee
On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng
wrote: If I'm diagnosing correctly, with python 2.6, the generated package files contain a ".PKGINFO" file, while python2.7 creates packages containing a file "./.PKGINFO" and libalpm complains saying the package is malformed.
Looking quickly at the code here, I'm a bit surprised how we do it. The behavior of os.walk() might have changed in what it is returning?
It prepends "./", probably because we call os.walk("."). There's a trivial fix, but I just find it terribly ugly. -- Rémy
On Mon, Sep 27, 2010 at 1:22 PM, Rémy Oudompheng
Dan McGee
wrote: On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng
wrote: If I'm diagnosing correctly, with python 2.6, the generated package files contain a ".PKGINFO" file, while python2.7 creates packages containing a file "./.PKGINFO" and libalpm complains saying the package is malformed.
Looking quickly at the code here, I'm a bit surprised how we do it. The behavior of os.walk() might have changed in what it is returning?
It prepends "./", probably because we call os.walk("."). There's a trivial fix, but I just find it terribly ugly.
A trivial fix that doesn't work for anything pre-2.7 though, which is bad news. -Dan
Dan McGee
A trivial fix that doesn't work for anything pre-2.7 though, which is bad news.
May I suggest this much less ugly patch ? The idea of recursively adding non-recursively things seems indeed very odd. -- Rémy.
On 28/09/10 05:00, Rémy Oudompheng wrote:
Dan McGee
wrote: A trivial fix that doesn't work for anything pre-2.7 though, which is bad news.
May I suggest this much less ugly patch ? The idea of recursively adding non-recursively things seems indeed very odd.
diff --git a/test/pacman/pmpkg.py b/test/pacman/pmpkg.py index 48d79a3..1d55175 100755 --- a/test/pacman/pmpkg.py +++ b/test/pacman/pmpkg.py @@ -164,14 +164,8 @@ def makepkg(self, path): # Generate package archive tar = tarfile.open(self.path, "w:gz") - - # package files - for root, dirs, files in os.walk('.'): - for d in dirs: - tar.add(os.path.join(root, d), recursive=False) - for f in files: - tar.add(os.path.join(root, f)) - + for i in os.listdir("."): + tar.add(i) tar.close() os.chdir(curdir) That looks fine to me... but then again, I seem to be missing the whole point of non-recursively adding directories in the first place. I have put this on my working branch in the meantime. Allan
On 28/09/10 12:24, Allan McRae wrote:
On 28/09/10 05:00, Rémy Oudompheng wrote:
Dan McGee
wrote: A trivial fix that doesn't work for anything pre-2.7 though, which is bad news.
May I suggest this much less ugly patch ? The idea of recursively adding non-recursively things seems indeed very odd.
diff --git a/test/pacman/pmpkg.py b/test/pacman/pmpkg.py index 48d79a3..1d55175 100755 --- a/test/pacman/pmpkg.py +++ b/test/pacman/pmpkg.py @@ -164,14 +164,8 @@ def makepkg(self, path):
# Generate package archive tar = tarfile.open(self.path, "w:gz") - - # package files - for root, dirs, files in os.walk('.'): - for d in dirs: - tar.add(os.path.join(root, d), recursive=False) - for f in files: - tar.add(os.path.join(root, f)) - + for i in os.listdir("."): + tar.add(i) tar.close()
os.chdir(curdir)
That looks fine to me... but then again, I seem to be missing the whole point of non-recursively adding directories in the first place.
I have put this on my working branch in the meantime.
Forgot. Tested python-2.6 and python-2.7. We also have python-2.5 in the list of usable python's so it may be worth someone running the test suite with that just to double check everything is still fine there. Allan
On Mon, Sep 27, 2010 at 9:24 PM, Allan McRae
On 28/09/10 05:00, Rémy Oudompheng wrote:
Dan McGee
wrote: A trivial fix that doesn't work for anything pre-2.7 though, which is bad news.
May I suggest this much less ugly patch ? The idea of recursively adding non-recursively things seems indeed very odd.
diff --git a/test/pacman/pmpkg.py b/test/pacman/pmpkg.py index 48d79a3..1d55175 100755 --- a/test/pacman/pmpkg.py +++ b/test/pacman/pmpkg.py @@ -164,14 +164,8 @@ def makepkg(self, path):
# Generate package archive tar = tarfile.open(self.path, "w:gz") - - # package files - for root, dirs, files in os.walk('.'): - for d in dirs: - tar.add(os.path.join(root, d), recursive=False) - for f in files: - tar.add(os.path.join(root, f)) - + for i in os.listdir("."): + tar.add(i) tar.close()
os.chdir(curdir)
That looks fine to me... but then again, I seem to be missing the whole point of non-recursively adding directories in the first place.
Xavier, any insight or memory why you did it this way?
commit c465d9e848b19b495259c7021a583c29fba92b44
Author: Chantry Xavier
On Tue, Sep 28, 2010 at 4:23 PM, Dan McGee
Xavier, any insight or memory why you did it this way?
commit c465d9e848b19b495259c7021a583c29fba92b44 Author: Chantry Xavier
Date: Thu Apr 17 09:02:11 2008 +0200 pactest : Use tarfile module.
There was no reason to write it that way, it looks quite stupid, but it's just the first method I found and it worked. I found an old mail when I was looking how to replace the 'tar cf *' call with python tarfile. os.listdir is actually closer to * than os.walk.
I looked a bit at using tarfile, my main problem is the *, I am not sure this is available in python. And I don't know how to emulate it either (all files/dirs in the current directory that dont start with . ?)
participants (4)
-
Allan McRae
-
Dan McGee
-
Rémy Oudompheng
-
Xavier Chantry