#21: command line option parsing
-------------------------------+--------------------------------------------
Reporter: was | Owner: jdemeyer
Type: enhancement | Status: needs_work
Priority: critical | Milestone: sage-6.0
Component: interfaces | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: #9958 | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by rohana):
Replying to [comment:45 kini]:
> Right, we might have a very thin bash wrapper that loads `sage-env`
(which will be a bash script) before the main Python script. Or, since
`sage-env` ideally should just set up environment variables and do nothing
else (right?), we could turn it into a config file that was read
independently by `sage-sh` and by `sage`. This would also allow us to rely
less on environment variables for random things seemingly unrelated to the
shell.
Are you saying that a configuration file should store the current
environment? And that anytime it is changed (such as if the root directory
of sage is moved) that this should be updated?
>
> The problem with having two-pass argument parsing is that it separates
the processing of arguments into multiple areas, making the architecture
of the startup process needlessly complex. It is also pretty ugly to
actually do this in the standard option parsing way because either you
start to want to enforce arbitrary argument orders like we currently do
(`sage -tp` works and `sage -pt` doesn't, `sage -br` works and `sage -rb`
doesn't, etc.), or now the bash script needs to basically reimplement
optparse/argparse in bash in order to correctly read the flags it's
looking for.
Also
* argparse/optparse handles help functionality (consistent formatting),
so all pre-parsed commands would still need stubs in argparse/optparse
(and -1 for code duplication)
* argparse (and maybe optparse) matches subcommands so long as they are
not ambiguous. So if (for instance) sage only had the subcommands foo and
bar then `sage f [args]` would be expanded to `sage foo [args]`. (this is
fairly standard for software with subcommands) This functionality would be
inconsistent if there were any pre-parsed commands.
> In any case, if I as a new Sage developer want to know or modify what
option `--foo` does, there should be one obvious place to look for it.
Making `sage-sh` parse arguments also means that we are shadowing
arguments that could be passed on to the shell, etc. etc. Splitting
argument parsing into two places is just generally a nasty design IMHO.
+1
> Why does part of the startup need to be bash, other than because of
`sage-env`?
For one of two reasons:
* python may not be in `PATH` because python is not currently a
dependency
* even if python is in `PATH`, sage may not work with the default python
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/21#comment:46>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
