unpin ipython==8.6.0 for branch 3.0

[jsvob]

All Pull Requests:

Check all that apply:

• Have you followed the guidelines in our Contributing document, including the instructions about commit messages?
• Is this PR to correct an issue?
• Is this PR an enhancement?

Complete Description of Additions/Changes:

The 3.0 branch is designed to run with Python 3.6. The pinned version of ipython is not compatible with Python 3.6. The pinning makes running pip install -e ".[develop]" impossible. As a result, setting up a fresh development environment is impossible without removing the pin. I'm not sure whether #3615 was meant to be backported to 3.0.

[ryan-blakley]

So I don't want to modify/diverge the 3.0 branch's setup.py file from master, because it would require two commits each time a change is needed to the file and it might get overwritten by accident when cherry picking. Additionally the 3.0 branch is the release branch it's not intended to develop with, and it isn't designed to run on only 3.6. The develop branch is generally meant to run on the latest version available in RHEL which is 3.9 right now.

The PR you referenced was submitted to address broken doc build tests on PRs that broke due to a newer ipython version. Is this just affecting your local setup or a test in another project. I can play around with making changes to require a different version on 3.6, but it would require going back and pinning other module versions as well for 3.6.

[ryan-blakley]

@jsvob Could you test if changing the line to ipython!=8.7.0 works for you in 3.6? That should allow the docs build test to work off master and for it to work on the 3.0 branch on 3.6.

[ryan-blakley]

Actually we discuss this in our PR meeting, and setting to ipython<8.7.0 should be better until we can confirm the fix is fixed in a future ipython version. Also please make this change to both branches not just the 3.0 branch.

[bfahr]

@jsvob I think you just need to resubmit the change as a new PR. The change you've made is correct but at least some of the errors are due to the fact that the commits on the 3.0 branch have been cherry-picked from master and don't match-up.

[jsvob]

Thanks. That's strange. I created a new local branch with the same name but based on master and force-pushed it to my remote, and changed this PR to merge to master. It seems github or CI just caches something, even though from the perspective of git-as-a-graph it makes no sense for github to fail like that.
New PR: #3630

[jsvob]

Closed in favor of #3630