-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If interactive, use IPython if available #189
Conversation
This pull request has been around for almost a year. Some brainstorm-like questions to get it going again:
|
In any case, you'll need to add a test and some documentation (in some cases, just a changelog entry might be enough). |
Not exactly hard coding a dependency, it just uses it if it's available. The way I wrote it might look like it needs IPython, but it's just checking if it's there and if not, run the same code as before.
It may not be the best option. It may be better to give this str parameters, so other projects can use it appropriately.
It could. However, #235 wouldn't solve the problem completely. If I understand it correctly, it will still run
Whereas IPython needs to run:
An env variable could be made such as PYTHONCONSOLE or something like it. What do you think? |
Ok, I like the idea. ipython is used a lot, so a special case for that seems reasonable. The try/except/else makes me feel a little bit stupid though. I never understand such a statement :-) Would something like this be clearer? It'd make my head hurt less, but it might be a bit over the top.
A better alternative might be to just add a simple comment line right after the "except" saying "no ipython detected, running the regular python interpreter". Yes, I like that one more :-) |
ce75a99
to
6c5d9d8
Compare
How about this? I reduced the number of lines by using |
Looks much nicer, imho, thanks. I don't think there's much that can be tested about this. I assume you've tried it out already with ipython in place and verified it worked? Do you have a suggestion for a changelog entry as documentation? (You can also merge master and add a changelog entry yourself, but I suspect just typing something here is easier :-) ) |
I wouldn't mind adding a unittest to avoid possible future regressions. I just need to familiarize myself with the test suite in this project. Changelog entry:
|
If you're adding a unittest, please merge master first. Test suite: mostly doctests. So... they do the job and the test coverage is pretty good. But it can be hard to get your head around them. The thing you're testing? Doesn't look too bad. There are 2 or 3 tests that directly test the creation of such an interpreter script. Perhaps only test that there's a string "IPython" in them? To get the tests running, just follow the short instructions in |
Thank you. It will probably wait until next week. |
@jimfulton: sounds fair. So perhaps simply an => Add a separate option and it'll be easier to use and it'll be more explicit. |
I would name it |
I'm sorry where is this What if I like developing and prototyping with ipython for the tab completion but I don't want to deploy ipython in production. |
@jimfulton is right: using ipython if some old version of ipython is on the I don't like having an extra option, however. There are enough options as-is. And having buildout itself depend on something? I doubt that's something we want to do. To me, there seems an easy solution: don't try/except to import ipython, but look if it is in the working set. The "try/except import" might give you a weird old version that you installed years ago. Checking the working set tells you if the user explicitly wanted ipython to be available. Which probably means, in 95% of the cases, that you preferably want to use ipython as interactive shell. The advantage of the "working set" approach is that you don't have an extra option and that you also don't have an extra buildout dependency. @jimfulton: how does that sound? @bwrsandman: don't worry, I'm willing to help with getting the working set stuff in :-) (Warning: I'm on holiday in 1.5 weeks, though). |
On Mon, Jul 6, 2015 at 5:52 PM, Reinout van Rees notifications@github.com
How would buildout depend on ipython (other than having code to import it)? I doubt that's something we want to do.
So if something I depend on happens to depend on ipython, my environment I wonder if this can be better done with a recipe, possibly with some help Jim Jim Fulton |
This got me thinking. To me, it seems like it is already possible without any modification! I just tried it locally and it works like a charm.
This way you'll get a @bwrsandman: can you try if that solves your use case? |
I tried on https://github.com/anybox/anybox.recipe.odoo which is what I use every day, it doesn't seem to do anything. But it might just be a particularity of that implementation. |
Hi @bwrsandman, Please find a minimalistic example here: Since it's so easy to get an IPython interpreter in the expected buildout context, I think we should close this PR. |
I tried it out. I see two issues. Major: the ipython script doesn't export the globals |
@bwrsandman, You can do both with the I've updated the gist adding also Modifying the banner is left as a (much more challenging) exercise for the reader. |
@leorochael thank you for the tip, this PR is no longer necessary. |
No description provided.