Closed alope107 closed 9 years ago
If we persist it to an IPython startup file, it won't be shell or env dependent. What do you think about doing that?
Sounds like a good idea to me. Do you think it's worth having the shell config edits as an option as well, or should I just replace this PR with one that only has an option for the IPython startup?
Good question. The shell variables would be useful for scripts outside IPython, for instance, but I'm not sure how valuable that is. I happen to have a very strong preference against things that touch my bashrc, but the persist option is off by default, so it's probably okay.
WIth all that, I am probably ever-so-slightly against saving to the shell rc, but if someone has a compelling reason to do it, it should be fine.
I added the option to write to an IPython profile as well. It can create a new profile or append to an existing one. I was unsure whether it would be preferable to call IPython's profile commands through subprocess or directly through the IPython core classes. This commit uses subprocess. Would you favor the other approach?
Thanks for the feedback. I've incorporated the suggested changes.
Code now only appends to existing config files. I don't have a particular reason for configuring csh other than supporting more environments.
In that case, I'd probably remove csh until a user explicitly asks for it.
OK, I'll take it out. Is the reasoning that we don't want to put on the burden of maintaining features that we don't know are being used?
Yup, to some degree.
Adds a
persist_changes
option that appends commands to set the required environment variables to .bashrc and .cshrc so that findspark only needs to be called once.