Re: [sage-devel] Re: creating notebook spkg
William Stein
>
> On Mon, Mar 30, 2009 at 7:29 PM, William Stein <wst...@gmail.com> wrote:
>>
>> On Mon, Mar 30, 2009 at 5:54 PM, Ondrej Certik <ond...@certik.cz> wrote:
>>>
>>> Hi,
>>>
>>> I was looking a bit at what actually has to be done to get a useful
>>> notebook.spkg, that can be installed without installing
>>> sage-3.4.1.alpha0.spkg and most of it's dependencies. E.g. that is
>>> useful for the windows port as well, as far as I understand.
>>>
>>> It seems to me that the sage notebook is pure python, so if I go to
>>
>> It doesn't depend at all on any real mathematics. But it does depend
>> a little maybe on some *cython* code, which isn't pure Python. E.g.,
>> the misc directory and sage_object.pyx.
>>
>>> sage/server and do:
>>>
>>> $ ipython
>>> Python 2.6.1+ (r261:67515, Mar 19 2009, 14:08:48)
>>> Type "copyright", "credits" or "license" for more information.
>>>
>>> IPython 0.9.1 -- An enhanced Interactive Python.
>>> ? -> Introduction and overview of IPython's features.
>>> %quickref -> Quick reference.
>>> help -> Python's own help system.
>>> object? -> Details about 'object'. ?object also works, ?? prints more.
>>>
>>> In [1]: from notebook.all import notebook
>>> ---------------------------------------------------------------------------
>>> ImportError Traceback (most recent call last)
>>>
>>> /home/ondrej/ext/sage-3.4.1.alpha0/spkg/standard/sage-3.4.1.alpha0/sage/server/<ipython
>>> console> in <module>()
>>>
>>> /home/ondrej/ext/sage-3.4.1.alpha0/spkg/standard/sage-3.4.1.alpha0/sage/server/notebook/all.py
>>> in <module>()
>>> 13 from sage_email import email
>>> 14
>>> ---> 15 from notebook_object import notebook, inotebook
>>> 16
>>> 17 from interact import interact, input_box, slider,
>>> range_slider, selector, checkbox, input_grid, text_control
>>>
>>> /home/ondrej/ext/sage-3.4.1.alpha0/spkg/standard/sage-3.4.1.alpha0/sage/server/notebook/notebook_object.py
>>> in <module>()
>>> 17 import time, os, shutil, signal, tempfile
>>> 18
>>> ---> 19 import notebook as _notebook
>>> 20
>>> 21 import run_notebook
>>>
>>> /home/ondrej/ext/sage-3.4.1.alpha0/spkg/standard/sage-3.4.1.alpha0/sage/server/notebook/notebook.py
>>> in <module>()
>>> 20
>>> 21 # Sage libraries
>>>
>>> ---> 22 from sage.structure.sage_object import SageObject, load
>>> 23 from sage.misc.misc import (alarm, cancel_alarm,
>>> 24 tmp_dir, pad_zeros, cputime)
>>>
>>> ImportError: No module named sage.structure.sage_object
>>>
>>> In [2]:
>>>
>>> then all that has to be done is to take some things from Sage, e.g.
>>> sage.structure.sage_object.SageObject and similar. Those are in
>>> Cython.
>>>
>>> I am doing it right now, I'll see if more problems pop up, or if it's
>>> just this. I'll report here.
>>>
>>
>> You might find sage/server/notebook/run_notebook.py very interesting,
>> in particular the part that starts:
>> -----
>> config.write("""
>> ####################################################################
>> # WARNING -- Do not edit this file! It is autogenerated each time
>> # the notebook(...) command is executed.
>> ####################################################################
>> from twisted.internet import reactor
>> ....
>> -----
>>
>> You'll see what from the Sage notebook gets imported when the actual
>> server is run, i.e., when the twistedconf.tac file is fed to the
>> twisted daemon script.
>>
>> Regarding longterm maintainable, what I recommend is:
>> (1) that you make a new setup.py file
>> (2) that you refactor a little code in interfaces/expect.py so that
>> it doesn't depend on the sage math library.
>>
>> You could do 1-2 after you just get stuff to work. The cool thing is
>> that with this approach one can just do something like
>>
>> python setup-notebook.py sdist
>>
>> and get a source tarball for the notebook part of Sage, and this can
>> 100% coexist with the current Sage library distribution.
>
> Ok, I reduced the whole sage spkg package just to:
>
> $ ls
> all_cmdline.py all_notebook.py all.py categories ext __init__.py
> __init__.pyc misc server structure version.py
>
> and it still seems to build and the notebook works. I'll now strip it
I don't buy this for a second! You're being misled somehow. At a
bare minimum, the interfaces directory is needed, since the notebook
communicates with all the worksheet processes via an expect interface,
which is defined in that directory.
William
> even further. And later implement (1) and (2) as you suggested.
>
> Ondra
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Ondrej Certik
Yes, I was just about to send the following email:
On Mon, Mar 30, 2009 at 8:20 PM, Brian Granger <elliso...@gmail.com> wrote:
>
> Nice! What are the dependencies fir this?
I think just twisted, maybe openssl.
So I tried to strip the whole sage-...spkg package, but I didn't
manage to make it installable in the end -- almost everything depended
on everything (like rings, polynomials, NTL, etc.) - and it once
looked I managed to get rid of it, but it failed to install in the
end.
https://bitbucket.org/certik/sage-341alpha0/
The problem was that I needed to delete everything between the
installs, but I was just doing sage -b.
Tomorrow I am busy, but on Wednesday I'll try the other approach, just
take the notebook and put in things that are needed, that should be
fairly simple, hopefully. I will have to write my own setup.py
probably, but since that is needed anyway in the long term, it should
work.
Or maybe combinations of the above. I think I know understand a bit
what is needed for what.
Ondrej
William Stein
the notebook, and which *do* depend
on the sage library for various conversions. The plan has been to
refactor those file into two, so all sage-library specific code goes
in derived classes. Then Sage and the Sage notebook would have richer
versions of each of the interfaces.
E.g., magma.py would be replaced by magma_base.py and magma.py, and
magma_base.py would not depend on the sage library, but magma.py would
still depend. You would ship magma_base.py but not magma.py.
> looked I managed to get rid of it, but it failed to install in the
> end.
>
> https://bitbucket.org/certik/sage-341alpha0/
>
> The problem was that I needed to delete everything between the
> installs, but I was just doing sage -b.
>
> Tomorrow I am busy, but on Wednesday I'll try the other approach, just
> take the notebook and put in things that are needed, that should be
> fairly simple, hopefully. I will have to write my own setup.py
> probably, but since that is needed anyway in the long term, it should
> work.
sage/interfaces/. That can't be avoided, and won't be trivial (but
certainly not impossible).
>
> Or maybe combinations of the above. I think I know understand a bit
> what is needed for what.
>
> Ondrej
>
> >
>
Ondrej Certik
I looked at magma.py. It's a python file, thus it doesn't affect the
actual installation, only runtime (correct?).
Here is what gets imported in it:
from sage.structure.parent import Parent
from sage.structure.element import RingElement
from expect import console, Expect, ExpectElement, ExpectFunction,
FunctionElement
import sage.misc.misc
import sage.misc.sage_eval
So shiping the Parent, RingElement etc. with the notebook should fix
it, doesn't it?
I had bigger problems, that some stuff in .pyx files from
sage/categories depended on rings and NTL etc., and that was giving me
hard time to get rid of. Also getting rid of sage/rings turned very
hard, as I think some stuff in sage.structure.parent depended on it.
So I think before refactoring interfaces, I first need to fix the pyx
files to actually compile.
Or did you mean, that the notebook should *not* ship Parent,
RingElement, etc. And to do that, some refactoring is needed?
I see, that makes sense. Well, I think I should be able to make it at
least install. If it fails at runtime, that for example
interface/magma.py doesn't import, well, that could be fixed later.
Looking at the notebook, it seems to me that magma.py is imported
dynamically, e.g. if the user doesn't set the magma interpreter, maybe
it is not imported at all?
>
>
>> looked I managed to get rid of it, but it failed to install in the
>> end.
>>
>> https://bitbucket.org/certik/sage-341alpha0/
>>
>> The problem was that I needed to delete everything between the
>> installs, but I was just doing sage -b.
>
> Yes, I suspected that.
>
>>
>> Tomorrow I am busy, but on Wednesday I'll try the other approach, just
>> take the notebook and put in things that are needed, that should be
>> fairly simple, hopefully. I will have to write my own setup.py
>> probably, but since that is needed anyway in the long term, it should
>> work.
>
> It will be absolutely essential to do some refactoring of code in
> sage/interfaces/. That can't be avoided, and won't be trivial (but
> certainly not impossible).
Ah, ok. In this case it is a little more work than I expected. I have
most of Wednesday to work on it, but I suspect I would need more time
for it.
Ondrej
William Stein
> actual installation, only runtime (correct?).
>
> Here is what gets imported in it:
>
> from sage.structure.parent import Parent
> from sage.structure.element import RingElement
> from expect import console, Expect, ExpectElement, ExpectFunction,
> FunctionElement
> import sage.misc.misc
> import sage.misc.sage_eval
>
> So shiping the Parent, RingElement etc. with the notebook should fix
> it, doesn't it?
>
> I had bigger problems, that some stuff in .pyx files from
> sage/categories depended on rings and NTL etc., and that was giving me
> hard time to get rid of. Also getting rid of sage/rings turned very
> hard, as I think some stuff in sage.structure.parent depended on it.
>
> So I think before refactoring interfaces, I first need to fix the pyx
> files to actually compile.
>
> Or did you mean, that the notebook should *not* ship Parent,
> RingElement, etc. And to do that, some refactoring is needed?
>
> I see, that makes sense. Well, I think I should be able to make it at
> least install. If it fails at runtime, that for example
> interface/magma.py doesn't import, well, that could be fixed later.
> Looking at the notebook, it seems to me that magma.py is imported
> dynamically, e.g. if the user doesn't set the magma interpreter, maybe
> it is not imported at all?
>
>>
>>
>>> looked I managed to get rid of it, but it failed to install in the
>>> end.
>>>
>>> https://bitbucket.org/certik/sage-341alpha0/
>>>
>>> The problem was that I needed to delete everything between the
>>> installs, but I was just doing sage -b.
>>
>> Yes, I suspected that.
>>
>>>
>>> Tomorrow I am busy, but on Wednesday I'll try the other approach, just
>>> take the notebook and put in things that are needed, that should be
>>> fairly simple, hopefully. I will have to write my own setup.py
>>> probably, but since that is needed anyway in the long term, it should
>>> work.
>>
>> It will be absolutely essential to do some refactoring of code in
>> sage/interfaces/. That can't be avoided, and won't be trivial (but
>> certainly not impossible).
>
> Ah, ok. In this case it is a little more work than I expected. I have
> most of Wednesday to work on it, but I suspect I would need more time
> for it.
>
> Ondrej
>
> >
>
Ondrej Certik
>
>> I looked at magma.py. It's a python file, thus it doesn't affect the
>> actual installation, only runtime (correct?).
>>
>> Here is what gets imported in it:
>>
>> from sage.structure.parent import Parent
>> from sage.structure.element import RingElement
>> from expect import console, Expect, ExpectElement, ExpectFunction,
>> FunctionElement
>> import sage.misc.misc
>> import sage.misc.sage_eval
>>
>> So shiping the Parent, RingElement etc. with the notebook should fix
>> it, doesn't it?
>>
>> I had bigger problems, that some stuff in .pyx files from
>> sage/categories depended on rings and NTL etc., and that was giving me
>> hard time to get rid of. Also getting rid of sage/rings turned very
>> hard, as I think some stuff in sage.structure.parent depended on it.
>>
>> So I think before refactoring interfaces, I first need to fix the pyx
>> files to actually compile.
>>
>> Or did you mean, that the notebook should *not* ship Parent,
>> RingElement, etc. And to do that, some refactoring is needed?
>
> Yes, absolutely. That's precisely what I mean.
Ok, that makes sense. I'll try to look into it.
Ondrej