[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 <allan@archlinux.org> 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. -- Rémy
On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Allan McRae <allan@archlinux.org> 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 <dpmcgee@gmail.com> wrote:
On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng <remyoudompheng@gmail.com> 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 <remyoudompheng@gmail.com> wrote:
Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Sep 27, 2010 at 12:31 PM, Rémy Oudompheng <remyoudompheng@gmail.com> 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 <dpmcgee@gmail.com> 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. -- Rémy.
On 28/09/10 05:00, Rémy Oudompheng wrote:
Dan McGee<dpmcgee@gmail.com> 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<dpmcgee@gmail.com> 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 <allan@archlinux.org> wrote:
On 28/09/10 05:00, Rémy Oudompheng wrote:
Dan McGee<dpmcgee@gmail.com> 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 <shiningxc@gmail.com> Date: Thu Apr 17 09:02:11 2008 +0200 pactest : Use tarfile module.
On Tue, Sep 28, 2010 at 4:23 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Xavier, any insight or memory why you did it this way?
commit c465d9e848b19b495259c7021a583c29fba92b44 Author: Chantry Xavier <shiningxc@gmail.com> 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