python-devel-tools

[wrobell]

On Fri, Apr 30, 2004 at 10:32:52AM +0200, Jacek Konieczny wrote:
> On Thu, Apr 29, 2004 at 11:21:53PM +0200, wrobell wrote:
> > On Wed, Apr 28, 2004 at 02:17:36PM +0200, Jacek Konieczny wrote:
> > > On Tue, Apr 27, 2004 at 09:37:56PM +0200, wrobell wrote:
> > > > tak sie zastanawiam... moze po prostu wyciac dodawanie aktualnej sciezki
> > > > skryptu do sys.path w pythonie? czy to jest tak naprawde potrzebne?
> > > 
> > > To jest część standardu.
> > pytanie gdzie opisanego? :-)
> > 
> > http://docs.python.org/lib/module-site.html
> > 
> > > Tego nie można tak po prostu wywalić.
> > powoduje to jednak okreslone problemy, jak sie okazuje.
> 
> Oraz daje wymierne korzyści (odpalanie skryptów bez instalacji).
> 
> > nic z automatu sie tutaj nie szuka. jak wrzucisz biblioteke .so do
> > /usr/lib/dziwnasciezka, to musisz sobie dokonfigurowac system
> > lub ustawic LD_LIBRARY_PATH albo kombinowac z LD_PRELOAD (czy jak jej tam...).
> 
> Ale python z automatu nie szuka "gdzie popadnie", ani nawet w $PATH. On
> szuka tam gdzie leży skrypt.
i to jest blad, np.:

stworz skrypt o nazwie getpass.py i umiesc go w $HOME/bin:

        import getpass
        passwd = getpass.getpass()

dlaczego getpass.py? jest to intyuicyjne dla mnie. skrypt jest
napisany w pythonie, wiec ma rozszerzenie .py, a nazywa sie
getpass, poniewaz chce pobrac haslo od uruchamiajacego ten skrypt

problem nr 1:

    > python bin/getpass.py
    Traceback (most recent call last):
      File "bin/getpass.py", line 1, in ?
        import getpass
      File "/home/users/wrobell/bin/getpass.py", line 3, in ?
        passwd = getpass.getpass()
    TypeError: 'module' object is not callable

imho, uzytkownik nie moze byz zmuszany w tym przypadku do zmiany
nazwy skryptu. malo tego, python zawiera duzo roznych modulow
i kazdy ma sobie teraz robic blacklist-e jak nie moga sie nazywac
jego skrypty (conajmniej 200 nazw w moim systemie)?


problem nr 2: jesli sciagniesz dowolny program napisany w pythonie, ktory
korzysta z modulu getpass i wrzucisz ten program do $HOME/bin, to program
sie nie uruchomi w _najlepszym_przypadku_

jak dla mnie mamy wiecej z obecnym zachowaniem pythona problemow niz pozytku.

> Przed chwilą sprawdziłem i okazuje się, że python szuka tam gdzie
> faktycznie leży skrypt, nawet gdy ten został odpalony przez symlink. 
> W tym momencie sprawa bardzo się ułatwia - właściwy skrypt dajemy do
> innego katalogu - tam gdzie są dodatkowe modułu dla tego skryptu lub do
> jakiegoś uniwersalnego "worka" na skrypty w pythonie (lepiej nie w
> /usr/{lib,share}/python, jeśli to nie jest moduł/pakiet do użycia przez
> inne aplikacje), a w $PATH dawać jedynie symlinki do skryptu. Żadnego
> $PYTHONPATH nie trzeba wtedy ustawiać, ani sys.path modyfikować w
> skrypcie. IMHO bomba.

wszystko swietnie dla prostych przypadkow. niestety, wszystko jest bardziej
skomplikowane i w przypadku takich systemow jak windows, gdzie programy
sa wrzucane do swoich wlasnych katalogow, moze jest to wygodne, ale w przypadku
standardow unix-owych powoduje to realne i trudne do obejscia (tworzenie
wrapperow i kombinajce z sys.path w porownaniu do ustawiania PYTHONPATH) problemy

> Przy okazji dowiedziałem się że nie muszę kombinować w moich projektach
> pythonowych z modyfikacją sys.path, aby skrypt umieszczony w $PATH
> znajdował swoje moduły :-)

do czasu az wrzucisz sobie jakis skrypt do $HOME/bin :-)

    wrobell <wrobell w pld-linux.org>