A tool for Python - request for some advice

[TPJ]

First I have to admit that my English isn't good enough. I'm still
studying and sometimes I just can't express what I want to express.


A few weeks ago I've written 'Python Builder' - a bash script that
allows anyone to download, compile (with flags given by user) and
install Python and some external modules (e.g. wxPython, PyGTK,
Numeric...). I use Python every day and when new version of Python (or
some external module) is released, I want to check if my projects will
run on this new version (sometimes I want to know if my projects will
run on specific combination of older Python and some older external
modules...). It happens four - five times a year. Frequently not enough
to memorize all commands used to configure, compile and install all of
this software (so I have to read documentation every time I'm doing it)
- but frequently enough to consume considerable amounts of my working
time. So I thought that writing a script to do it all automatically
(download sources, unpack them, configure them, compile them and then
install them; all of this with options given by me - the user) would be
a good idea.

(It's not about using emerge, get-apt or some another tool of this
kind. My need is very special - I want to have Python, it's modules and
sometimes documentation installed in particular place; usually
somewhere in my home directory. My script installs some additional
scripts which I can use to run Python. These additional scripts have
properly set LD_LIBRARY_PATH so they are able to run Python and
external modules that require libraries installed in non-standard
locations.)

I've written this script in bash, because I thought it would be better
to have a script which would run in environment without Python (it all
was about installing Python anyway!). I used bash, dialog, wget... And
now someone suggested, that I shuld use Python. That using Python would
lead to clearer and - probably - smaller code. (I have to admit it - my
code in bash is just messy.)

And now I'm considering this idea. Python is already present on
(almost?) every distribution today, so why worry about it's presence?
Writing in Python would lead to easier i18n (for now it's all in
Polish...) and to easier implementation of future enhancements (due to
language's features and much more clearer coding style in Python). Well
- I've already found it hard to implement new features in pure bash.

But, on the other hand, I'm thinking that writing in bash is more
universal solution. I mean that requirements to run bash scripts are
lower than requirements to run Python scripts. Could this requirements
be decisive for some users (or is it only my imagination)? Sometimes
users just have no access to Python (e.g. LFS, some stages of Gentoo,
some rescue and specialized distros).


And there's also something more. For now "Python Builder" works in text
mode. It was written in bash and I assumed it should be some kind of
"basic" tool - so text mode and bash seemed to be the best choice. But
if I rewrote all code in Python I could make some GUI. It could works
even better - I could easily check if GUI mode is available and run in
proper (GUI or text) mode. But is GUI needed by people who just want it
to do it's job and quit?


Well, what do you think?

 

[Brian van den Broek]

TPJ said unto the world upon 21/06/2005 02:00:

First I have to admit that my English isn't good enough. I'm still
studying and sometimes I just can't express what I want to express.

I've graded essays in Philosophy at my university that were written by
native speakers of English yet were substantially less clear and well
written than your post. I don't think you will need to lead with an
apology for your language skills in the future

A few weeks ago I've written 'Python Builder' - a bash script that
allows anyone to download, compile (with flags given by user) and
install Python and some external modules (e.g. wxPython, PyGTK,

kind. My need is very special - I want to have Python, it's modules and
sometimes documentation installed in particular place; usually
somewhere in my home directory. My script installs some additional

I've written this script in bash, because I thought it would be better
to have a script which would run in environment without Python (it all
was about installing Python anyway!). I used bash, dialog, wget... And
now someone suggested, that I shuld use Python. That using Python would
lead to clearer and - probably - smaller code. (I have to admit it - my
code in bash is just messy.)

And now I'm considering this idea. Python is already present on
(almost?) every distribution today, so why worry about it's presence?

But, on the other hand, I'm thinking that writing in bash is more
universal solution. I mean that requirements to run bash scripts are
lower than requirements to run Python scripts. Could this requirements
be decisive for some users (or is it only my imagination)? Sometimes
users just have no access to Python (e.g. LFS, some stages of Gentoo,
some rescue and specialized distros).

Well, what do you think?

I'm not a sophisticated programmer (I wouldn't know a bash script if
it bit me).

So, to make sure I've understood (the issue is my level of knowledge,
not your level of English): you want to provide a specialized install
script for Python (3rd party modules, non-standard locations, etc.)
You started in bash to deal with minority cases without an extant
Python install. But clearly, there will be a Python install by the
time your bash script is done, or something will have gone very wrong.

That suggests implementing the custom installation work in Python, and
having a bash script that will

1) determine if there is an existing Python install,
2) if there is not, install Python in the standard way,
3) using the now guaranteed to be there installation of Python, run
your Python script that does all of your custom installation, and
4) if step (2) added a Python installation other than the one added by
step (3), perhaps remove it.

Am I missing some reason why that wouldn't be a satisfactory option?
(This is entirely possible

Best,

Brian vdB

 

[Robert Kern]

That suggests implementing the custom installation work in Python, and
having a bash script that will

1) determine if there is an existing Python install,
2) if there is not, install Python in the standard way,
3) using the now guaranteed to be there installation of Python, run
your Python script that does all of your custom installation, and
4) if step (2) added a Python installation other than the one added by
step (3), perhaps remove it.

Allow me to second that advice and also point out some work that should
make step 3 easier in the, hopefully near, future:

http://peak.telecommunity.com/DevCenter/EasyInstall

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Peter Maas]

First I have to admit that my English isn't good enough. I'm still
studying and sometimes I just can't express what I want to express.

No excuses, please! Keep in mind that your English is much better than
the Polish of most of us. And just in case you were fishing for
compliments:

Your English IS good enough.

 

[Mike Meyer]

I've written this script in bash, because I thought it would be better
to have a script which would run in environment without Python (it all
was about installing Python anyway!). I used bash, dialog, wget... And
now someone suggested, that I shuld use Python. That using Python would
lead to clearer and - probably - smaller code. (I have to admit it - my
code in bash is just messy.)

And now I'm considering this idea. Python is already present on
(almost?) every distribution today, so why worry about it's presence?

Is your target platform Linux? I've seen the claim that every Linux
distro comes with Python installed, but can't verify it.

On the other hand, not every Unix distribution comes with Python
installed. BSD systems for instance tend to be pretty
minimalist. Solaris isn't minimalist, but you have to get Python from
a third party. This is probably true of other commercial Unix
distributions as well. MacOS X is a known exception - it comes with
Python preinstalled.

Then again, the same comments apply to bash. Distributions that have
their roots in AT&T Unix probably don't come with bash by default,
with Mac OS X being an exception. This makes depending on bash a bad
idea if you want to write a script that portable across Unix distros.

If your target platform is Linux, indications are that python is as
portable as bash. If your target platform is Unix, then the same is
true - except you shouldn't be writing bash if you want
portability. Try reading <URL:
http://www.bsdatwork.com/2004/03/04/what_to_watch_out_for_when_writing_portable_shell_scripts/

for what's involved in writing portable shell scripts.

<mike

 

[TPJ]

(...) I've seen the claim that every Linux

distro comes with Python installed, but can't verify it.

So have I. And I think it might be truth. The only problem is that
different distros might be released with different versions of Python.

Then again, the same comments apply to bash. Distributions that have
their roots in AT&T Unix probably don't come with bash by default,
with Mac OS X being an exception. This makes depending on bash a bad
idea if you want to write a script that portable across Unix distros.

Good to know. So my script written in bash will be primary targeted for
Linux distros. OK, I can live with that.

If your target platform is Linux, indications are that python is as
portable as bash.

I've thought about it for a few days and I disagree with you. Python
isn't as portable as bash because of one reason. The problem is that
development of Python is much more dynamic than development of bash. If
I wrote my script in Python it would be possible that this script
wouldn't run on the same distro with _different_ version of Python.

(This is problem because someone has sugested that he'd like to run
this script on RH 9. So older distros must be considered as well as
newer.)

As long as I'm using bash, I'll deal with a tool that has the same
features on different distros (well... _almost_ the same features)

(This is about portability, of course. There are also another
advantages of using bash.)

If your target platform is Unix, then the same is true - except you
shouldn't be writing bash if you want portability.

Well, my primary goal is Linux. I'm working on Linux and I have no
access to any *BSD system (or another flavour of Unix). I thought that
bash scripts are portable, but now I can see I was wrong.

Thanks for all your help.

 

[TPJ]

So, to make sure I've understood (...) : you want to provide
a specialized install script for Python (3rd party modules,
non-standard locations, etc.)
yes

You started in bash to deal with minority cases without an extant
Python install.

My motivation was rather to avoid a bootstrap-like problems. I thought
that writing a script in _Python_ for compiling _Python_ is just silly
idea. I thought that bash (available even in rescue distros!) would be
a better tool.

But clearly, there will be a Python install by the
time your bash script is done, or something will have gone very wrong.
yes

That suggests implementing the custom installation work in Python, and
having a bash script that will

<snip>

Well... not exactly.

My primary goal is to save time spent on downloading, uncompressing,
reading documentation, configuring, compiling and installing software.
So I want to write a tool that would allow me to spent a few minutes to
tell it what to do - and then it would do it all. I would pay attention
to this tool for a few minutes, instead of wasting much more time doing
it all myself.

I could check for a Python installation and install Python in standard
way in case Python wouldn't be available but this would have following
disadvantages:
1) It would be a large waste of time spent on installing Python in
standard way. (Especially if user wouldn't like _standard_ Python
installation. I'm working on this script because in most situations I'm
not happy with such standard installation!)
2) It would lead to download a particular Python's version for a
temporary purpose - and this means additional waste of time and
bandwith.

For now my script works as follows:
1) It allows user to configure all options and actions.
2) When user is ready it just does what it is supposed to do.

The first stage is very important - it takes a few minutes and then all
is done automatically.


Thanks for your advice - it was really helpful.

 

[TPJ]

I've heard about this "EasyInstall" and I like this idea.

If EI becomes a part of Python's standard library, my script will use
it.

 

[Robert Kern]

I've heard about this "EasyInstall" and I like this idea.

If EI becomes a part of Python's standard library, my script will use
it.

Why wait? Just make it the second thing that the script installs after
Python itself.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Terry Hancock]

I've thought about it for a few days and I disagree with you. Python
isn't as portable as bash because of one reason. The problem is that
development of Python is much more dynamic than development of bash. If
I wrote my script in Python it would be possible that this script
wouldn't run on the same distro with _different_ version of Python.

(This is problem because someone has sugested that he'd like to run
this script on RH 9. So older distros must be considered as well as
newer.)

If you write your scripts to work with Python 2.1, they will work on
practically any Linux distribution that is still in wide use on desktops
and servers. You might get into trouble on embedded systems or
"rescue disk" Linuxes (i.e. you might have to go back to 1.5).