[Python-mode] python-mode modifies load-path emacs-wide.

[Cavesnow]

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

> Andreas can answer that, but I can say that python-mode.el should be
> loadable
> standalone.  It can use optional additional tools, but loading
> python-mode.el
> should not break if it can't find them, and basic editing, syntax
> highlighting, etc. should just continue to work.

This is certainly true.

> Rather, I think the right way to do this is to leave load-path hackery
> up to
> the user, but python-mode.el should have something like:
>
> (condition-case nil
>     (require 'pycomplete)
>   (error))
>

As you say this will not break the python-mode functionality if
pycomplete should not be present.
However I think there is a decision to make: if pycomplete is an
additional part of python-mode then it is logical that the user should
not have to worry too much about load-path hackery and a fallback should
be provided. Something like:

(or
 (require 'pycomplete nil t)
 (let ((load-path (add-to-list 'load-path (concat py-library-path
						  "completion"))))
   (if (locate-library "pycomplete")
       (load-library "pycomplete")
        nil
     )
   )
 )


That returns nil if pycomplete is not available.
On the other hand if pycomplete should be able to exist alone from
python this is not necessary. However I cannot imagine why this should
be the case: pycomplete requires python-mode and cannot exist separately...

There is also a blueprint to deliver a ready to use pymacs. In the
perspective of this tighter integration I think this fallback options
should be provided. For example pycomplete has a line that says

(pymacs-load "pycomplete")

that tries to load the pycomplete.py python part of the code that
normally sits in the same dir as pycomplete.el

A user wanting to use this functionality has to copy the pycomplete.py
to a location searched by pymacs-load-path (the variable pymacs uses for
searching for its scripts) or modify the pymacs-load-path itself. This
actually means that providing a working python environment requires a
lot of hassle from the user. On the other hand if these checks were
implemented we could be sure that
1) If the user specifies the needed paths, user preference would always
be honored
2) However if the packages are not found in the user dirs then
python-mode could search inside it's own dirs.

What do you think of this?
On 08/16/2011 11:58 PM, Barry Warsaw wrote:
> On Aug 16, 2011, at 11:07 PM, Cavesnow wrote:
> 
>> I will try to explain my idea a bit better. Removing part with 	the
>> direct modification of load-path I think is clear: a library shouldn't
>> interfer with global settings.
> 
> Agreed.
> 
>> If I understand correctly pycomplete would probably be loaded from inside
>> python-mode and it is not meant to be a stand-alone library. Correct me if I
>> am wrong.
> 
> Andreas can answer that, but I can say that python-mode.el should be loadable
> standalone.  It can use optional additional tools, but loading python-mode.el
> should not break if it can't find them, and basic editing, syntax
> highlighting, etc. should just continue to work.
> 
>> Anyway, since I have not found any place in the python-mode.el file
>> where pycomplete.el nor did I find any auto-load instructions I thought of
>> this solution. Let's say that at a certain point python-mode wanted to use
>> functions provided in pycomplete and thus had to load it as a library. My
>> idea was that in that case the loading was to be made this way:
> 
>> (let ((load-path (add-to-list 'load-path (concat py-library-path
>> "completion"))))
>>  (load-library "pycomplete")
>>  )
> 
> Rather, I think the right way to do this is to leave load-path hackery up to
> the user, but python-mode.el should have something like:
> 
> (condition-case nil
>     (require 'pycomplete)
>   (error))
> 
> to just ignore it if it can't be found (or *maybe* echo a warning).
> 
> Cheers,
> -Barry
_______________________________________________
Python-mode mailing list
Python-mode at python.org
http://mail.python.org/mailman/listinfo/python-mode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOS436AAoJEGWa0uAesZr4cscP/0Q89cN3pIMUtQ05Igg0WGBE
Vpiqjl0eIXiMv7z5b+aHn7Saffn8MHM5xLAC7CFt9OGLJQG9nLHtId67zLm7Pyxo
pIbToBZlswkxh0MOir3mkdJ7H2uHc5h7vsZBzfAUguAtw+MRXDsbs9wDiHifr441
V5T78IDbkgibwz6NkaBC+jSqCKzLFuYmDbmmB/Pe8ovoWF4QPQ7aqYhVsPP05OJP
ZCkUx9t2wGZ99b5kRAlG0z6VPQqV9uI7lHDtIRKoUz6LTo3AIRciD3HZEVofANgq
fMC4nP8obXol0C9v+Jaropmk7E9MOcVR2AZwLGr6pvkS2UYurV6Qp0fO9vWNmop7
asKnplHnpUWjnRp+IVLGWGtlheZalB86TWZyBkWg3vO7dWfvL++jkVEbnueJ8lPk
Vk2z+xzOzZLy3ITasZ65xPa/4meuHwcVHRuyngNkGxFNz3SvatWlx5XrB/EoLdxN
RibzY+YrqE23j4x/l9HtVfWeppSHxzeHp2kEdPCZYqXKOIwmVq4iIkLszmVru6ID
hfgLl8GznS8ReDgvIiIlPyG8va4zKNivpg+psz7WNUzmmDRM5uCg705OCLKCzfMP
ciN9C53p42qd9H1NMiOa3XfI0NhQRDnrMxjiCI+/tRFwnNvGmJSyALUidl75E7XD
K6ZYEf0+0Vlxlr2reffN
=sptR
-----END PGP SIGNATURE-----