System wide install?

[Ivan Iakoupov]

Hello
I've recently tried out symbide and it seems quite promising to me. It
runs quite well on Gentoo amd64 after hunting down all those
dependencies. (I plan to test it on WinXP some day, but I'm just to lazy
to install all those dependencies right now :) )

However I couldn't find a way to install it systemwide. If it had a
standard distutils based install it wouldn't be much of a problem. Is it
possible that such a way would be introduced in the future?

Actually I even tried hacking my own setup.py for it but hit a brick
wall when I saw that symbide still has to have write access to some
directories. I think that those should be possible to handle in a
gracious way somehow. Currently my thoughts are:
1. split into a 'symbide' package and scripts, i.e. move 'Symbide.py'
(and 'Com.py'?) out of 'symbide' directory.
2. move 'examples' to the 'symbide' directory to have everything in one
place. Then symbide/settings and symbide/examples could be copied on
first run to ~/.symbide on linux or somewhere to the Application Data
directory on Windows.
3. Get rid of 'temp' somehow. I'm not sure what its function is but you
should be either able to use standard 'tempfile' module or use
'home'/'Application Data' instead.
4. I don't know how to handle 'tests' however. Maybe some inspiration
could be found in other python modules (I know for sure that 'scipy' has
extensive tests for example)
5. In the end it should be rather easy to make a setup.py script, which
will take care of making 'Symbide.py' (and 'Com.py'?) executable (on
Gentoo the standard wrapper for distutils even puts it into /usr/bin, I
don't know whether distutils do that on Ubuntu.). On windows some post
installation script trickery might be required to make a shortcut to
script(s).

[Ivan Iakoupov]

On Dec 13, 5:55 pm, Ivan Iakoupov <vox...@gmail.com> wrote:

> 1. split into a 'symbide' package and scripts, i.e. move 'Symbide.py'
> (and 'Com.py'?) out of 'symbide' directory.

That was about version 0.2.1. I can see layout of the trunk has
changed a lot. But basically what I meant is to have a 'symbide'
python package with all the needed auxiliary files (which don't change
at runtime) and a script which imports that package.

P.S.
Also the current trunk would only work on Python 2.5 or higher. <2.5
don't support combing except and finally:
http://docs.python.org/whatsnew/pep-341.html

[basti]

Hi Ivan,
nice to hear from someone who tried out symbide!

>However I couldn't find a way to install it systemwide. If it had a
>standard distutils based install it wouldn't be much of a problem. Is it
>possible that such a way would be introduced in the future?

This truely would be a very nice thing to have, but until now I really
had no motivation to deal with installation routines.
I always run the svn version directly and there are many other ideas I
would like to implement.
(I hope you tried out the svn version too, because since the last
release, several new features were added and the directory structure
changed too.)

>Actually I even tried hacking my own setup.py.

Awesome!

>1. split into a 'symbide' package and scripts, i.e. move 'Symbide.py'
>(and 'Com.py'?) out of 'symbide' directory.
>2. move 'examples' to the 'symbide' directory to have everything in one
>place. Then symbide/settings and symbide/examples could be copied on
>first run to ~/.symbide on linux or somewhere to the Application Data
>directory on Windows.

I don't know if there are any common ways to structure a project, but
that sounds reasonable.

3. Get rid of 'temp' somehow. I'm not sure what its function is but
you
should be either able to use standard 'tempfile' module or use
'home'/'Application Data' instead.

In "temp" the following things are stored:
* html files (created for html previews)
* log files (some steps of every execution are logged for easier
debugging)
* pictures (all plots created by Gnuplot, Sympyplot or Matplotlib
are stored there)
* worksheets (the worksheets that were opened when symbide get's
closed are stored. If they were saved before, only the path is stored,
otherwise the whole worksheet is saved in this folder)

The first three things can easily be handled with tempfiles, but the
worksheets have to be stored untill the next session. (Maybe in the
users home directory.)

>4. I don't know how to handle 'tests' however. Maybe some inspiration
>could be found in other python modules (I know for sure that 'scipy' has
>extensive tests for example)

What do you mean by handle tests? They don't need write access!?
Or do you just don't like the way they are integrated?

>5. In the end it should be rather easy to make a setup.py script, which
>will take care of making 'Symbide.py' (and 'Com.py'?) executable (on
>Gentoo the standard wrapper for distutils even puts it into /usr/bin, I
>don't know whether distutils do that on Ubuntu.). On windows some post
>installation script trickery might be required to make a shortcut to
>script(s).

Would be great if you could go on writing a setup script ;)

basti

[basti]

> P.S.
> Also the current trunk would only work on Python 2.5 or higher. <2.5
> don't support combing except and finally:http://docs.python.org/whatsnew/pep-341.html

I changed this statement. (I hope you meant pyparsing.py)
Are there any other things that don't work for Python <2.5?
I'm wondering you're not mentioning ctypes. Were they included <2.5?
Nevertheless I will try to get rid of them too.

[Ivan Iakoupov]

basti wrote:
>> 4. I don't know how to handle 'tests' however. Maybe some inspiration
>> could be found in other python modules (I know for sure that 'scipy' has
>> extensive tests for example)
>
> What do you mean by handle tests? They don't need write access!?
> Or do you just don't like the way they are integrated?
>

Yes I assumed that they needed wright access too.

>> 5. In the end it should be rather easy to make a setup.py script, which
>> will take care of making 'Symbide.py' (and 'Com.py'?) executable (on
>> Gentoo the standard wrapper for distutils even puts it into /usr/bin, I
>> don't know whether distutils do that on Ubuntu.). On windows some post
>> installation script trickery might be required to make a shortcut to
>> script(s).
>
> Would be great if you could go on writing a setup script ;)

There actually isn't much to it. I'm attaching (I hope it works) my
setup.py and MANIFEST.in in their current non-working state.
They assume a directory structure:

INSTALL
LICENSE
setup.py
Symbide.py
symbide/
__init__.py
examples/<file>
settings/<dir>/<file>
<...>
paths.xml
<...>

[Ivan Iakoupov]

basti wrote:
>> P.S.
>> Also the current trunk would only work on Python 2.5 or higher. <2.5
>> don't support combing except and finally:http://docs.python.org/whatsnew/pep-341.html
>
> I changed this statement. (I hope you meant pyparsing.py)

Mine bailed out on errorWidget.py

> Are there any other things that don't work for Python <2.5?

Currently I don't know any other way to find out than to just try your
next trunk revision and see what happens :)

> I'm wondering you're not mentioning ctypes. Were they included <2.5?
> Nevertheless I will try to get rid of them too.

ctypes weren't much of a problem... it's just an emerge away ;)

[basti]

> Mine bailed out on errorWidget.py

This should be fixed now in svn-trunk.

[basti]

> setup(name='symbide',
> version='0.2.1',
> description='Symbide is a graphical working environment for Python, similar to the Mathematica Notebook.',
> #author='',
> #author_email='',
> url='http://code.google.com/p/symbide/',
> packages=packages,
> scripts=['Symbide.py'],
> package_data={'symbide':['examples/*.*', 'settings/*/*.*', 'paths.xml']},
> requires=['sympy', 'numpy', 'Gnuplot', 'gtk', 'pylab', 'PIL'],
> provides=['symbide'],
> )


Does require mean it won't work without these packages?
This wouldn't be true, because it should be possible to use symbide
without any of them except for gtk.

[Ivan Iakoupov]

Well I had no idea... Just saw them being imported in your main
__init__.py file without noticing that it also handles import failures.
But 'requires' and 'provides' are not supported in 2.4 anyway (distutils
gives a warning on them), so maybe they should be nuked altogether. On a
side note I actually have absolutely no idea, what those lines could be
used for - actual dependencies are handled by packages managers in their
own format. Maybe easy_install uses it somehow...

Also forgot to mention that INSTALL.in goes in the same directory as
setup.py

[basti]

Thanks very much for your effort so far.
I'll fix some other important issues the next days and then try to get
installation working for the next release.
If you have further suggestions please post them.

basti