Bug#484305: PoC not working for bicyclerepair

[James Vega]

On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> Hi Thomas,
> * Thomas Arendsen Hein <thomas at intevation.de> [2008-07-06 22:53]:
> > * Steffen Joeris <steffen.joeris at skolelinux.de> [20080706 11:15]:
> > > severity 484305 important
> > > thanks
> > 
> > Please do not downgrade severity without providing a reason.
> 
> "critical makes unrelated software on the system (or the whole system) 
> break, or causes serious data loss, or introduces a security 
> hole on systems where you install the package."
> 
> I had a look at the issue now and this is not the case 
> because you have to a) install vim-python and bicyclerepair 
> together and b) set vim.python as the vim alternative.
> Thus downgrading this bug.

In Lenny/Sid, all Vim packages except vim-tiny and vim contain the
python support, so it is more likely that a user will have a vim binary
that can be scripted via Python.

On the other hand, in Lenny/Sid the path that plugins used to be
installed to (/usr/share/vim/addons) is no longer automatically included
in Vim's runtimepath.  This means that manual work is required to enable
the plugin.

> [...] 
> > On etch:
> > 
> > $ dpkg -l bicyclerepair|grep ^i
> > ii  bicyclerepair       0.9-4.1             A refactoring tool for python
> > 
> > $ dpkg -L bicyclerepair|grep vim
> > /usr/share/doc/bicyclerepair/README.vim
> > /usr/share/vim
> > /usr/share/vim/vim62
> > /usr/share/vim/vim62/plugin
> > /usr/share/vim/vim62/plugin/bike.vim
> > /usr/share/vim/vim63
> > /usr/share/vim/vim63/plugin
> > /usr/share/vim/vim63/plugin/bike.vim
> > /usr/share/vim/addons
> > /usr/share/vim/addons/plugin
> > /usr/share/vim/addons/plugin/bike.vim
> > 
> > Maybe (I haven't verified) you need:
> > /etc/alternatives/vim -> /usr/bin/vim.python
> 
> Indeed, this is needed (+ installation of vim-python).
> So to sum up you need to install vim-python and set the 
> alternative to vim.python. I am not sure about the status of 
> this in unstable, at least I could not reproduce this on 
> unstable but vim.python is also no longer available there, 
> a lot in the vim structure changed since then and I don't 
> really have an idea about the scripting support of vim.
> 
> That's why I Cc'ed the vim maintainers. Do you think this 
> should also work in the same way in unstable/testing?

See above explanation.

Also, taking a look at the current bicyclerepair package, the addon is
now installed to /usr/share/addons/vim/ftplugin/python_bike.vim.  This
means that the functionality will only be used when editing python files
(once the user has enabled the plugin) instead of when editing any file,
as was the case when it was installed to plugins/bike.vim.

> I am also not really sure what is causing the automatic 
> import.

Python, by default, has '' as the initial item in its sys.path list

  $ python
  Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
  [GCC 4.3.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import sys
  >>> sys.path
  ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0']

This means that anything in the current directory is first priority when
trying to use/import a module.

/usr/lib/pythonX.Y/compiler/transformer.py has the following lines that
are run when the module is imported

  import token
  ...
  _cmp_types = {
      token.LESS : '<',
      token.GREATER : '>',
      token.EQEQUAL : '==',
      token.EQUAL : '==',
      token.LESSEQUAL : '<=',
      token.GREATEREQUAL : '>=',
      token.NOTEQUAL : '!=',
      }

When the bike Vim plugin is loaded, it imports the bike python module,
which imports compiler (and therefore compiler.transformer).  Since
Vim's current working directory is roundup-X.Y/roundup, the above lines
from transformer.py combined with '' being the first item in sys.path
cause python to load the token module in the current working directory
(from roundup's source) instead of using /usr/lib/pythonX.Y/token.py.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20080707/2b846b88/attachment.pgp