bzr fails with 'iteration over non-sequence' in _get_bug_fix_properties

[Jan Kybic]

Starting with bzr later than version 0.15, most commands (like 'ci'), failed with a message like the one given below, while
bzr version 0.15 worked fine:

[kybic.d620-jk ~/work/frae]> bzr ci -m 'added files'
bzr: ERROR: exceptions.TypeError: iteration over non-sequence

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 817, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 779, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 477, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.4/site-packages/bzrlib/builtins.py", line 2249, in run
    bug_property = self._get_bug_fix_properties(fixes, tree.branch)
  File "/usr/lib/python2.4/site-packages/bzrlib/builtins.py", line 2206, in _get_bug_fix_properties
    for fixed_bug in fixes:
TypeError: iteration over non-sequence

bzr 0.90.0 on python 2.4.4.final.0 (linux2)
arguments: ['/usr/bin/bzr', 'ci', '-m', 'added files']

** please send this report to <email address hidden>

-------------

Solution: I added one line before line 2206 in file builtins.py, so that 'fixes' is tested for None. This seems to have fixed the problem.
Here is the relevant section of builtins.py:

    def _get_bug_fix_properties(self, fixes, branch):
        properties = []
        # Configure the properties for bug fixing attributes.
 if fixes is not None: # THIS LINE ADDED BY JAN KYBIC
          for fixed_bug in fixes: # HERE IT USED TO FAIL

[Martin Pool (mbp)]

Hi Jan,

Thanks for the report and the fix. I'd like to understand just when this occurs so that we can add a test for it and see if it can crop up in any other places. For me, ci does not fail when run in a newly created branch. Do you know how to reproduce this?

[Jan Kybic (kybic)]

> Thanks for the report and the fix. I'd like to understand just when
> this occurs so that we can add a test for it and see if it can crop up
> in any other places. For me, ci does not fail when run in a newly
> created branch. Do you know how to reproduce this?

Yes, for me it always fails on a newly created branch. I am sending an example.
I am running a Gentoo Linux. What other information do you need?

Jan

[kybic.d620-jk ~/tmp]> mkdir bzrtest
[kybic.d620-jk ~/tmp]> cd bzrtest
[kybic.d620-jk ~/tmp/bzrtest]> bzr init
[kybic.d620-jk ~/tmp/bzrtest]> touch a
[kybic.d620-jk ~/tmp/bzrtest]> bzr add a
added a
[kybic.d620-jk ~/tmp/bzrtest]> bzr ci
bzr: ERROR: exceptions.TypeError: iteration over non-sequence

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 817, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 779, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 477, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.4/site-packages/bzrlib/builtins.py", line 2249, in run
    bug_property = self._get_bug_fix_properties(fixes, tree.branch)
  File "/usr/lib/python2.4/site-packages/bzrlib/builtins.py", line 2207, in _get_bug_fix_properties
    for fixed_bug in fixes:
TypeError: iteration over non-sequence

bzr 0.90.0 on python 2.4.4.final.0 (linux2)
arguments: ['/usr/bin/bzr', 'ci']

** please send this report to <email address hidden>

--
-------------------------------------------------------------------------
Jan Kybic <email address hidden> tel. [phone]
http://cmp.felk.cvut.cz/~kybic ICQ 200569450

[Vincent Ladeuil (vila)]

I encountered the same bug coming from a different path: I was trying to use a builtins.cmd_commit object without providing a 'fixes' parameter.

Also Jan's fix is correct, I'd like to mention that the bug IMHO is in the default value for a ListOption ('fixes' is the only option of that type in bzr code base).

--- bzrlib/builtins.py 2007-09-11 00:27:26 +0000
+++ bzrlib/builtins.py 2007-09-13 16:58:05 +0000
@@ -2251,7 +2257,7 @@

     def run(self, message=None, file=None, verbose=False, selected_list=None,
- unchanged=False, strict=False, local=False, fixes=None,
+ unchanged=False, strict=False, local=False, fixes=[],
             author=None, show_diff=False):

There are other tests for the cmd_commit object but they all provide 'fixes=[]'...

[Alexander Belchenko (bialix)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Kybic пишет:
>> Thanks for the report and the fix. I'd like to understand just when
>> this occurs so that we can add a test for it and see if it can crop up
>> in any other places. For me, ci does not fail when run in a newly
>> created branch. Do you know how to reproduce this?
>
> Yes, for me it always fails on a newly created branch. I am sending an example.
> I am running a Gentoo Linux. What other information do you need?

Do you have any plugins installed? If yes, could you provide output of
`bzr plugins`? I think this bug could be produced by some out of date plugin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8A7qzYr338mxwCURAjgpAJ4yq0hPNTV7mWq7eVibQbZr8D0ALgCeOi+Q
/xra/IIOvYLj4eIKRE5d04o=
=zZqW
-----END PGP SIGNATURE-----

[Jan Kybic (kybic)]

>> I am running a Gentoo Linux. What other information do you need?
>
> Do you have any plugins installed? If yes, could you provide output of
> `bzr plugins`? I think this bug could be produced by some out of date plugin.

I do not think so. Here is the output:

[kybic.d620-jk ~]> bzr plugins
/usr/lib/python2.4/site-packages/bzrlib/plugins/multiparent.pyc
        Implementation of multiparent diffs for versionedfile-like storage
/usr/lib/python2.4/site-packages/bzrlib/plugins/launchpad
        Launchpad.net integration plugin for Bazaar

Jan

--
-------------------------------------------------------------------------
Jan Kybic <email address hidden> tel. [phone]
http://cmp.felk.cvut.cz/~kybic ICQ 200569450

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

vila wrote:
> I encountered the same bug coming from a different path: I was trying to
> use a builtins.cmd_commit object without providing a 'fixes' parameter.
>
> Also Jan's fix is correct, I'd like to mention that the bug IMHO is in
> the default value for a ListOption ('fixes' is the only option of that
> type in bzr code base).
>
> --- bzrlib/builtins.py 2007-09-11 00:27:26 +0000
> +++ bzrlib/builtins.py 2007-09-13 16:58:05 +0000
> @@ -2251,7 +2257,7 @@
>
> def run(self, message=None, file=None, verbose=False, selected_list=None,
> - unchanged=False, strict=False, local=False, fixes=None,
> + unchanged=False, strict=False, local=False, fixes=[],
> author=None, show_diff=False):

An empty list should never be supplied as a default value, because list
is a mutable type. We don't want to open the door to the possibility
that this particular instance of the list will be changed.

While the empty tuple is similar to the empty list, the usual idiom is:

def foo(bar=None):
    if bar is None:
        bar = []

(It would be nice if a callable could be supplied as a default, rather
than an instance, because then we could do 'def foo(bar=list):' and
avoid the extra typing.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8DLn0F+nu1YWqI0RAllxAJ4yalEN+ldsOc5Us1EPO3O8ng+E/wCZAdHa
593mycM/GYyLtpoxAHfkRec=
=8s9I
-----END PGP SIGNATURE-----

[Vincent Ladeuil (vila)]

>>>>> "aaron" == Aaron Bentley writes:

    aaron> vila wrote:
    >> I encountered the same bug coming from a different path: I was trying to
    >> use a builtins.cmd_commit object without providing a 'fixes' parameter.
    >>
    >> Also Jan's fix is correct, I'd like to mention that the bug IMHO is in
    >> the default value for a ListOption ('fixes' is the only option of that
    >> type in bzr code base).
    >>
    >> --- bzrlib/builtins.py 2007-09-11 00:27:26 +0000
    >> +++ bzrlib/builtins.py 2007-09-13 16:58:05 +0000
    >> @@ -2251,7 +2257,7 @@
    >>
    >> def run(self, message=None, file=None, verbose=False, selected_list=None,
    >> - unchanged=False, strict=False, local=False, fixes=None,
    >> + unchanged=False, strict=False, local=False, fixes=[],
    >> author=None, show_diff=False):

    aaron> An empty list should never be supplied as a default
    aaron> value, because list is a mutable type. We don't want
    aaron> to open the door to the possibility that this
    aaron> particular instance of the list will be changed.

You realize that the cmd_commit.run() method, run during a 'bzr
commit' command line *always* receives a fixes=[] parameter, do
you ?

The door *is* open.

[Robert Collins (lifeless)]

On Tue, 2007-09-18 at 21:32 +0000, vila wrote:
>
> You realize that the cmd_commit.run() method, run during a 'bzr
> commit' command line *always* receives a fixes=[] parameter, do
> you ?
>
> The door *is* open.

Its a new list, it won't change global state.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Vincent Ladeuil (vila)]

Ghaaa, I was horribly confused. The door is not opened at all.