On Wed, 07 Feb 2007 17:15:38 -0700, Brian Granger <[EMAIL PROTECTED]> wrote:
> One of the things that Fernando and I got out of the workshop last
> week is how important it is to have seamless installation/deployment

Cool! There were many end users there, which really helps make this point clear.

> various options for making it easy for people to install ipython1.  We
> spent some time looking at your spkg scripts and they look like a nice
> lightweight way of helping people install a set of things.

Neat.  I'm glad you find them useful.  I wrote the first version of it
all over one weekend, because people kept complaining about having to
rebuild SAGE from scratch so many times.  They really are the simplest
possible package management system imaginable, I think.  They also have
been very well tested and got more polished over the last year.

> Our goal is to provide general users with a basic set of tools for
> scientific computing these include many of the things you already have
> (but not SAGE itself):

That makes a lot of sense.

> python
> ipython
> ipython1
> numpy
> hdf5
> openmpi/mpi4py
> pytables
> matplotlib
> pyrex
> scipy
> etc
>
> This is the semi-standard set of tools that people use for scientific
> computing in python.
>
> This week, I have spent time using your scripts and creating packages
> for these things.  I am simply using your scripts and makefiles and
> creating my own .spkgs.  It turns out that your scripts are very
> useful for buiding/deploying non-SAGE software as well.  We wanted to
> run a few things by you:

Wow, this is AWESOME!  It's wonderful, because it means that any SAGE user
will have access to all your core packages as optional package (which
they can just install with "sage -i"), and conversely users of your distro
will have the option of "sage -i"'ing many SAGE packages.   This could
really help with the maintenance work of keeping such packages up to date.
I've been meaning to make a pytables package, by the way, and I'm glad
you're doing so.

> 1.  It looks like your scripts are GPL.  Are we correct to think that
> we can use/distribute/modify the scripts as GPL, but without and of
> the actual SAGE libraries?  Because they are shell scripts and
> makefiles, we would obviously distribute source.

Yes, you can do so.  If you're uncomfortable with any license issues
involving the scripts, let me know.

> 2.  In certain cases I have simply used your existing .spkg for things
> (readline/termcap/python/twisted).  In most cases the .spkg are easy
> to create, but often it was just easier to reuse yours.  Are you OK
> with us using your packages and having the resulting library keep its
> original license?  For instance, can we use your python2.5 spkg and
> still have it be released under the Python software license?

Yes.  And please do!  It will help really help with maintenance of
these packages quite a lot.  Plus, there are benefits -- e.g., my
Python package will build on Itaniums, but the official Python distro
doesn't, and there also slight improvements to GMP, etc., in other packages.

> 3.  In certain cases, we need to modify your packages.  A couple of
> cases have come up:
>
> numpy/scipy - we will need to deal with the fortran compiler issue

Yep.  This is one of the hardest for me.  But it should be much easier
for you, since you guys are so knowledgeable about numpy/scipy (i'm pretty
naive).

> python - on mac os x we need to build python as a framework so the GUI
> version of matplotlib will work.  So far we are doing the GUI stuff
> through the GPL Qt4, but we eventually might want to include wx in
> order to use the enthought stuff.  Getting the framework python to
> work well was not trivial, but it seems to be working now.

??? How does this work?  I don't even know what you're talking about.
Could you elaborate slightly?    In any case, this sounds like it
would be useful for SAGE too.

> aix - one of our target platforms are the big supercomputers.  We will
> likely have to edit scripts to put in things to handle these systems.


Good. I would appreciate any fixes and improvements you discover.

> I would imagine that you might be interested in these modified
> packages?  If we are using some of your packages and you are using
> some of ours, it might make sense to coordinate efforts, even though
> our actual distributions won't contain the exact same set of packages.
>  Thoughts?

Yes!  And we can make it so "sage -i <packagename>" (or "ipython -i 
<packagename>")
will query both repositories.

I guess in a sense we are doing something like building the open
source world's analogue of the Maple / MATLAB relationship.

> 4.  Some of the top level scripts are tied into SAGE pretty strongly.
> Our users would no nothing of SAGE so it would be nice to decouple the
> spkg stuff from SAGE itself.  Our vision is that there would exist a
> general set of packages that various projects could use to build self
> contained software distributions using the spkg scripts/makefiles.
> The typical usage scenario is that a user would simply source sage-env
> (or a suitably renamed version) and then just use ipython/python/etc.
> That is, there top level entry point would not be SAGE, just plain
> python.  We would probably want to make changes the various sage
> scripts to reflect this difference?  My thought is that we would still
> call the packages .spkg and use the SAGE name in various contexts?
> Thoughts?

That would be fine with me.   Just like SUSE sometimes has
"rpms", and "r" stands for redhat.   I  would be especially
enthusiastic about the implementation of this decoupling if
I don't have to do the work.  Basically, if somebody else
does it, and it works as well as it works now (or better),
then I'm happy to switch to it.


> I wanted to get this discussion rolling as we already have a very
> usable distribution that we would like to begin distributing.  I
> should also say that our company would like to host the resulting
> distribution (as open source) and would also likely build internal
> projects (both open source and proprietary) around it.  But, the
> actual distribution would remain open source.

Sounds good to me.   Perhaps we could mirror copies of each other's
distributions?   If you look at http://sage.math.washington.edu/sage/
you'll see SAGE currently has 4 mirrors, and another would be good.

Willliam

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to