python-devel-tools

[wrobell]

On Sun, May 02, 2004 at 11:55:08AM +0200, Jacek Konieczny wrote:
> On Sun, May 02, 2004 at 11:47:45AM +0200, wrobell wrote:
> > On Sun, May 02, 2004 at 11:38:31AM +0200, Jacek Konieczny wrote:
> > > On Sun, May 02, 2004 at 11:32:21AM +0200, wrobell wrote:
> > > > > Czytałeś  co napisałem? Żadneg wrappera nie potrzeba (i ustawiania
> > > > > PYTHONPATH itp.). Wystarczy po prostu symlink.
> > > > tak, czytałem i specjalnie dla Ciebie powtórze moje pytania:
> > > > 1. jak to zrealizować przy obecnych założeniach dotyczących dostarczania
> > > >    kompilowanych wersji modułów w pld?
> > > 
> > > Skrypt wykonywalny nie jest modułem - nie będzie skompilowany, nie musi
> > > mieć (w katalogu w którym rzeczywiście leży) rozszerzenia ".py"
> > nieprawda, prosze sprawdz (np.: timeit.py, profile.py, pdb.py to sa
> > i moduly i skrypty)
> 
> To zrobić obok "timeit.py" "timeit", do którego będzie link
> %{_bidir}/timeit.py. Samo "timeit" zawierało by "import timeit"
> i kopię tego co jest w "if __init__ == __main:"
oj, to wiadomo. tak nawet moze skrypt shell-owy sie nazywac i nie
bedzie problemu. zreszta qboosh zmienil na timeit_py, pdb_py, profile_py,
itp. jednakze jest to _obejscie_ problemu, ktory jest stwarzany
przez obecne rozwiazanie w pythonie. w dodatku jest to obejscie
tylko na potrzeby pakietow pld. sam uzytkownik dalej zostaje na lodzie,
poniewaz jego skrypt nie moze nazywac sie odpowiednio jesli nie
zrobi trick-u (sic!) z sys.path.

> > > W FHS 2.3 nie widzę nic co zabraniałoby symlinków w %_bindir. O
> > > wszystkim co tam jest pisze zresztą "executable or symlink", więc nie
> > > widzę problemu.
> > ale exec bedzie w %py_sitedir lub %py_sitescriptdir - FHS czasami tego
> > nie zabrania?
> 
> Nic takiego nie widzę. Zresztą jakby zabraniał, to gdzie miałyby leżeć
> wszystkie pliki wykonywalne, które nie służą do bezpośredniego
> uruchomienia, więc nie powinny leżeć w $PATH?
/usr/libexec?

    wrobell <wrobell w pld-linux.org>