preparing for the first public release
Ondrej Certik
the current version number of SPD is 0.3, as I was using some other
code form qsnake etc.
Let's make the version of the next release 0.4 and then continue up to
1.0, where 1.0 would be really polished and tested distribution. We
can then follow the version numbers of Sage, or continue using 1.1,
1.2, etc.
Here are some issues that should be fixed before we release:
http://code.google.com/p/spdproject/issues/list?q=label:Milestone-Release0.4
and feel free to fix any other issue as well.
Brian, could you please test SPD on Mac Os X? And feel free to improve
the installation/build instructions.
Thanks,
Ondrej
Brian Granger
> the current version number of SPD is 0.3, as I was using some other
> code form qsnake etc.
>
> Let's make the version of the next release 0.4 and then continue up to
> 1.0, where 1.0 would be really polished and tested distribution. We
> can then follow the version numbers of Sage, or continue using 1.1,
> 1.2, etc.
> Here are some issues that should be fixed before we release:
>
> and feel free to fix any other issue as well.
> Brian, could you please test SPD on Mac Os X? And feel free to improve
> the installation/build instructions.
Cheers,
Brian
> Thanks,
> Ondrej
Ondrej Certik
>> the installation/build instructions.
>
> And also try the build on OS X.
Thanks. In the meantime I tested on OS X 10.5 Intel and it builds fine.
I am now working on automatic cpu number detection and implementing a
parallel build. I'll try to fix the other issues as well if I figure
it out.
Ondrej
Brian Granger
Cheers,
Brian
Ondrej Certik
>
> Yep, I just finished building it on my Mac and all went well.
Ok. One more question, that I don't have yet an opinion about:
I am thinking of creating
spd-0.4.tar.gz
which will be the 2MB base package
Then spd-python-0.4.tar.gz, that would include packages up to python+ipython
then spd-scipy-0.4.tar.gz, that would include all packages up to
numpy, scipy, sympy, ipython (maybe also openssl and foolscap, so that
ipython parallel runs just fine), but it would not contain the atlas
package, because it takes forever to build. When we figure out how to
extract the Sage notebook into a separate spkg, we would also include
it here.
then spd-scipy-atlas-0.4.tar.gz, which would be the same as spd-scipy,
just with the atlas package.
So basically the spd-scipy package would be the base package for
scientific python stuff. Then for our custom builds, e.g. electronic
structure, or finite elements, I guess we'll just take spd-scipy and
add our specific packages in it, e.g. cmake, mayavi2 for
visualization, etc.
Ondrej
William Stein
>
> On Sun, Mar 29, 2009 at 2:09 PM, Brian Granger <elliso...@gmail.com> wrote:
>>
>> Yep, I just finished building it on my Mac and all went well.
>
> Ok. One more question, that I don't have yet an opinion about:
>
> I am thinking of creating
>
> spd-0.4.tar.gz
>
> which will be the 2MB base package
>
> Then spd-python-0.4.tar.gz, that would include packages up to python+ipython
>
> then spd-scipy-0.4.tar.gz, that would include all packages up to
> numpy, scipy, sympy, ipython (maybe also openssl and foolscap, so that
Those should all be spd-scipy-0.4.tar (not .gz), right, since the
spkg's inside are already compressed.
> ipython parallel runs just fine), but it would not contain the atlas
> package, because it takes forever to build. When we figure out how to
On *most* systems ATLAS takes 10-20 minutes to build. I'm not sure
that is forever.
> extract the Sage notebook into a separate spkg, we would also include
> it here.
>
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Brian Granger
>
> spd-0.4.tar.gz
>
> which will be the 2MB base package
>
> Then spd-python-0.4.tar.gz, that would include packages up to python+ipython
>
> then spd-scipy-0.4.tar.gz, that would include all packages up to
> numpy, scipy, sympy, ipython (maybe also openssl and foolscap, so that
> ipython parallel runs just fine), but it would not contain the atlas
> package, because it takes forever to build. When we figure out how to
> extract the Sage notebook into a separate spkg, we would also include
> it here.
>
> then spd-scipy-atlas-0.4.tar.gz, which would be the same as spd-scipy,
> just with the atlas package.
there is a danger in doing this - you are creating lots of little
mini-distributions that will require maintenance (albeit not much) and
updating, etc.
One thing that would be really nice to have is to make it really easy
to generate such tarballs from a given spd install. In other words,
figure out which spkgs are currently installed and create an spd
tarball that has just those spkgs installed. Does that make sense.
For now, I would just create a base package that has:
python
ipython (and deps - don't forget twisted)
atlas (I agree with William that it is not that slow to build)
numpy
scipy
sympy
matplotlib?
I don't think there is a huge need to have a python+ipython package
only and one without atlas.
Cheers,
Brian
Ondrej Certik
>
>> I am thinking of creating
>>
>> spd-0.4.tar.gz
>>
>> which will be the 2MB base package
>>
>> Then spd-python-0.4.tar.gz, that would include packages up to python+ipython
>>
>> then spd-scipy-0.4.tar.gz, that would include all packages up to
>> numpy, scipy, sympy, ipython (maybe also openssl and foolscap, so that
>> ipython parallel runs just fine), but it would not contain the atlas
>> package, because it takes forever to build. When we figure out how to
>> extract the Sage notebook into a separate spkg, we would also include
>> it here.
>>
>> then spd-scipy-atlas-0.4.tar.gz, which would be the same as spd-scipy,
>> just with the atlas package.
>
> I see why you are thinking about making these various tarballs. But,
> there is a danger in doing this - you are creating lots of little
> mini-distributions that will require maintenance (albeit not much) and
> updating, etc.
Yes, exactly, I would like to avoid it if possible. Also it's
confusing to people.
>
> One thing that would be really nice to have is to make it really easy
> to generate such tarballs from a given spd install. In other words,
> figure out which spkgs are currently installed and create an spd
> tarball that has just those spkgs installed. Does that make sense.
You can get this list with
./spd -f
So maybe let's add a new command to ./spd that would download the bare
spd-0.4.tar, take the list of installed spkg packages (a-la ./spd -f),
or a list of packages on the commandline/from file, and it would build
the release tarball.
>
> For now, I would just create a base package that has:
>
> python
> ipython (and deps - don't forget twisted)
Here are the packages that I had to install for ipython parallel:
http://code.google.com/p/spdproject/wiki/AdditionalPackages
Those are:
twisted-8.1.0.p2
openssl-0.9.8d.p1
pyopenssl-0.6
foolscap-0.3.2.p0.spkg
ipython-bzr1160.spkg
So if twisted is not included, then ipython could not be used in
parallel, is that right?
Is it useful to have the parallel functionality available in the base
package? I would thought so. But if we decide not to, then we don't
have to install openssl and foolscap neither.
> atlas (I agree with William that it is not that slow to build)
Ok. For me it doubles (maybe more) the installation time, but let's
have it. I don't want to maintain more tarballs.
> numpy
> scipy
> sympy
> matplotlib?
>
> I don't think there is a huge need to have a python+ipython package
> only and one without atlas.
Right, seem reasonable. We'll maintain just the bare 2MB tarball, and
then spd-scipy tarball, this should cover most needs and then people
can install more packages into it.
Ondrej