Quoting VulK <[email protected]>:
Dear all,
this is my first post to gentoo-science and I am writing because I have some
problems running experimental code from the sage project.
My issue is the following:
I have sci-mathematics/sage-4.7-r2 installed from the sage-on-gentoo overlay
and I would like to install the combinat queue; I am following these
instructions: http://wiki.sagemath.org/combinat/MercurialStepByStep
The command I am supposed to run is
# sage -combinat install
unfortunately -combinat is not recognized by sage as a valid option. I
browsed a little bit around the filesystem and I noticed that $SAGE_ROOT is
empty (except for some documentation) while on other installations of sage
(not using the ebuilds) there is plenty of stuff including a devel/combinat
folder.
Is there an option I can use when installing sage to allow for experimental
sources? or is there any other way I can use queues without installing sage
not using portage?
Thanks
VulK
PS: some weird behaviour:
% sage -h
----------------------------------------------------------------------
| Sage Version 4.7, Release Date: 2011-05-23 |
----------------------------------------------------------------------
Optional arguments:
file.<sage|py|spyx> -- run given .sage, .py or .spyx files
-advanced -- list all command line options
-c <cmd> -- Evaluates cmd as sage code
-experimental -- list all experimental packages that can be installed
-gap [...] -- run Sage's Gap with given arguments
-gp [...] -- run Sage's PARI/GP calculator with given arguments
-h, -? -- print this help message
-i [packages] -- install the given Sage packages
-inotebook [...] -- start the *insecure* Sage notebook
-maxima [...] -- run Sage's Maxima with given arguments
-mwrank [...] -- run Sage's mwrank with given arguments
-n, -notebook [...] -- start the Sage notebook (options are the same
as for the notebook command in Sage)
-optional -- list all optional packages that can be installed
-python [...] -- run the Python interpreter
-R [...] -- run Sage's R with given arguments
-singular [...] -- run Sage's singular with given arguments
-root -- print the Sage root directory
-t [options] <files|dir>
-- test examples in .py, .pyx, .sage or .tex files
options:
-long -- include lines with the phrase
'long time'
-verbose -- print debugging output during
the test
-optional -- also test all #optional examples
-only-optional <tag1,...,tagn> -- only run tests
including one of the #optional tags
-randorder[=seed] -- randomize order of tests
-v, -version -- print the Sage version
% sage -experimental
sage-run received unknown option: -experimental
usage: sage [options]
Try 'sage -h' for more information.
Hi VuLK,
unfortunately at this stage we do not support that in sage-on-gentoo.
Actually the version we ship is stripped down in some ways.
Let me explain:
sage has its own upgrade system, it wouldn't work in the kind of
installation we
do and that would mean changing, adding and deleting files in the
system outside
the control of the package manager. We definitely don't want to do that. So we
removed the options for sage upgrade. The only option to upgrade is
portage/package-core etc...
There are options to help you create spkg, install spkg and so on, we could
probably give back the one to create spkg but we otherwise completely
circumvent the sage build system so the corresponding options are gone.
The main problem is that sage's normal distribution model is trying to be
developer friendly but isn't distro friendly. We coerced it into a
distro which
makes it more appealing for an end user to try but it is stripped of
some of the
dev-friendly features.
There are advantages and disadvantages for both models. We can be/are
more up to
date than sage with some packages. If I patch something I literally have to
reinstall the whole of of the sage spkg from portage, the equivalent of sage
-ba while from vanilla sage you could use sage -b and only rebuild the
necessary bits.
Now you are the first person making this kind of request about using something
like the combinat queue. We probably can give you an ebuild pulling the
combinat queue. There are just two caveats here:
1) it may take a bit of time for us to come up with something.
2) because I expect the queue to be somewhat in flux it would have to be a hot
ebuild of some kind. If you can live with that we can probably work something
out.
Francois
