Run from within a Jupyter Notebook
See original GitHub issueWhen the following code is run from a demo.py
file or from the Python interpreter, it runs as expected, collecting a new dataset. However, when run from within a Jupyter Notebook, it complains that KeyError: u'dallinger_email_password is not a valid configuration key'
.
import dallinger
experiment = dallinger.experiments.Bartlett1932()
data = experiment.collect(
app_id=u"3b9c2aeb-0eb7-4432-803e-bc437e17b3bb",
)
print(data.networks.list)
Test files:
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
Running Code — Jupyter Notebook 6.5.2 documentation
Alt-Enter runs the current cell and inserts a new one below. Ctrl-Enter run the current cell and enters command mode. Managing the Kernel ......
Read more >How to Use Jupyter Notebooks - Codecademy
To run a piece of code, click on the cell to select it, then press SHIFT+ENTER or press the play button in the...
Read more >Running the Notebook - Jupyter Documentation
Notebooks can be executed from your terminal using the run subcommand. It expects notebook paths as input arguments and accepts optional flags to...
Read more >Running a Jupyter notebook and its cells - YouTube
Interrupting and shutting down a Jupyter notebook · Setup Jupyter HotKey Shortcut to Run All - Avoid State problem in Jupyter Notebooks ·...
Read more >Running Jupyter Notebooks
Running a Jupyter Notebook from Another Jupyter Notebook¶ · From the left Sidebar, select and right-click on the Jupyter notebook that has to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@MatthewWilkes I don’t see any issue with using your fork. The pexpect license is permissive, and so if your contribution to pexpect is licensed under the same terms, it shouldn’t pose any problems.
With respect to NGS2, we promised that all the code produced as part of the program would be open source and permissively licensed, not that it’s specifically MIT licensed; this meets those requirements.
I’ve added PR #736 that works around this. Modifying pexpect turned out to be a rabbithole, it’s not possible to support its functionality adequately well enough to make something useful. A lot of the same fixes needed were in common with @jessesnyder #707 branch, which makes sense as they’re both about getting useful information from subprocesses when not using a terminal.