#21: command line option parsing
---------------------------+------------------------------------------------
Reporter: was | Owner: mabshoff
Type: enhancement | Status: needs_work
Priority: critical | Milestone: sage-5.0
Component: interfaces | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies: #9958
---------------------------+------------------------------------------------
Comment(by rohana):
Replying to [comment:28 kini]:
> Capital! :) As it's a large project maybe you could post WIPs once in a
while?
No problem, once I have something of any real substance, I'll be sure to
post it somewhere.
> I was planning on diving into the scripts dir myself and trying to work
on this, but I guess it should be an order of magnitude easier for you,
haha. Still, let me know if I can help with anything.
Well, I'm just starting and have had a busy week with other stuff, so you
would probably be in about as good of position as myself, especially since
we need to rebase this off of the 5.0 dev builds, which changed a lot of
that stuff anyway.
I'm finding myself annoyed at spkg/script, and all the little special
cases that we have. I really just want to rip that out and try to have a
(more) unified design to our parsing. My current fancy is to introduce a
bunch of subcommands, like mercurial or aptitude. Some of the ones I've
thought about:
{{{
% sage ARGS # this would be for running sage scripts, or a couple of
oddball arguments
% sage notebook ARGS
% sage pkg ARGS # this would include spkg stuff
% sage pkg install # since install has some special flags like -f or -s
% sage test ARGS
% sage build ARGS
% sage {python,sqlite3,R,gp,...} ARGS # we can consider these programs as
subcommands of sage
}}}
I haven't fully worked out what this would look like with all the
arguments (such as debugging), but IMO it would greatly clean up our
command line tools. Also, this would simplify many aspects of the
implementation, although some hacking of argparse will still have to be
done (it currently doesn't support optional subparsers, see
[http://bugs.python.org/issue9253]).
I probably should bring this up on the devel list, but I'm tired and
should go to bed before I have to be up in the morning :/.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/21#comment:29>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.