I'm willing to maintain the EPEL7 branch if none of the current maintainers are interested - right now I'm using the F19 builds of python-ipython-console and python-mglob and they work fine (the actual EPEL7 build should probably be of the newer 2.1.x series that doesn't need mglob anymore)

Sure, co-maintainers welcome :)

There seem to be many missing requirements on epel7:
DEBUG util.py:283:  Error: No Package found for fontawesome-fonts-web
DEBUG util.py:283:  Error: No Package found for mathjax
DEBUG util.py:283:  Error: No Package found for python-path
DEBUG util.py:283:  Error: No Package found for python-tornado >= 3.1.0

Thomas, I gave this to you since you seem to be taking care of it.  Michel, comaintainers welcome.  Just request access via the Fedora accounts system.

(In reply to David Cantrell from comment #3)
> Thomas, I gave this to you since you seem to be taking care of it.  Michel,
> comaintainers welcome.  Just request access via the Fedora accounts system.

I can do so, yet could need help with the final testing later on...

python-tornado is now available on epel7.

You can't ship a newer python-tornado in EPEL7 as it is already in RHEL7.

OK, ACL requested, thanks.

Thomas, which version is that for? Will try a local build on my CentOS 7 machine.

IPython needs at least python-tornado-3.1.

So we would need a python-tornado3 or something compat package or use a quite ancient ipython version.
I'm just trying to put a newer python-tornado into copr instead:
http://copr.fedoraproject.org/coprs/tomspur/ipython/

Aha, OK. I'm rebuilding the other dependencies in local mock at the moment, should I post the modified specs here and you can put them in that COPR repo?

OK, done with rebuilds; python-ipython-console installs fine but with the following oddity:

[TerminalIPythonApp] WARNING | Could not copy default file to static dir. Source file /usr/lib/python2.7/site-packages/IPython/html/static/custom/custom.js does not exist.
[TerminalIPythonApp] WARNING | Could not copy default file to static dir. Source file /usr/lib/python2.7/site-packages/IPython/html/static/custom/custom.css does not exist.

Turns out these files are shipped in python-ipython-notebook instead -- we should probably move them to python-ipython-console while updating it to use python-tornado3 in the epel branch.

Missing EPEL deps:

Can be simply rebuilt from master branch:
- fontawesome-fonts
- mathjax
- ttembed (needed to build fontawesome-fonts)

Need to downgrade to F19 branch:
- python-path (5.2 in master fails test suite when rebuilding on CentOS)

Need to create separate package:
- python-tornado

Any progress here?  I don't think we're going to see a python-tornado update in RHEL7 any time soon.  Worth shipping an old version in EPEL7 or just going the copr route?

ipython now even requires python-tornado >= 4.0 :/

I am not interested in maintaining it in EPEL7, so it Michel's decision to ship an old version or continue with the copr route...

(In reply to Thomas Spura from comment #11)
> ipython now even requires python-tornado >= 4.0 :/
> 
> I am not interested in maintaining it in EPEL7, so it Michel's decision to
> ship an old version or continue with the copr route...

An old ipython in EPEL would be really helpful in developing scripts for Fedora release engineering etc.

Michel - are you still interested in this?  What can we do to help?

Another possibility would be to not ship the notebook with the EPEL7 package.  This would presumably help Till/Infra.

Created attachment 995313 [details]
Do not package notebook on EPEL

This is a patch to allow building ipython without the notebook on EPEL, should we decide to go that route.

It would be nice to keep the BRs next to the Rs for the notebook.
Other than that, it seems doable.

(In reply to Orion Poplawski from comment #15)
> Created attachment 995313 [details]
> Do not package notebook on EPEL
> 
> This is a patch to allow building ipython without the notebook on EPEL,
> should we decide to go that route.

Works for me (with an error mentioned in comment 9), and I have built a scratch build for others to test it on http://koji.fedoraproject.org/koji/taskinfo?taskID=9089441

+1

(In reply to Thomas Spura from comment #16)
> It would be nice to keep the BRs next to the Rs for the notebook.
> Other than that, it seems doable.

The problem is that the BRs need to be outside of the %if 0%{?with_notebook} conditional.  Even though we are not shipping the notebook (because of missing python-tornado), they are needed to build the package.

(In reply to Matěj Cepl from comment #17)
> Works for me (with an error mentioned in comment 9)

Ah, forgot about that.  Moved those files into -console.  New build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9092410

The next question is which ipython version to use for EPEL. Without the notebook it should be possible to directly update to 2.5 (AFAIK),

I noticed that David is the official PoC for EPEL - @David: Do you have any objections about this plan?

The latest stable Ipython that I know of is 2.4.1, which is what I'm proposing to go with now.

(In reply to Orion Poplawski from comment #21)
> The latest stable Ipython that I know of is 2.4.1, which is what I'm
> proposing to go with now.

Ah, sorry, this was an off-by-one error - in Fedora there is still 2.3. Will you be fine with updating it to 3.0 once it is released (should happen soon according to Thomas), if not, it would be a good idea to introduce 2.4.1 only to testing initially to be able to update to 3.0 without potentially breaking stable updates.

(In reply to Orion Poplawski from comment #21)
> The latest stable Ipython that I know of is 2.4.1, which is what I'm
> proposing to go with now.

Is the essential problem that including a notebook which works with the version of tornado shipped in RHEL would mean downgrading ipython to a version believed to be too old? 

No matter what version is included now, ipython (and many scientific libraries) evolves fast enough that three years from now it may not be compatible with then-current software. But I may not understand the EPEL philosophy regarding updates, as comment #22 mentions updating to a new major release version and I thought that was not the enterprise way...

Notebook is the majority of my use, if it were up to me, I'd package the version of Ipython available when the RHEL7 packages were frozen; so that notebook could be included. If I need newer ipython I'll pip install it or use Fedora. I would expect EL packages to have old versions.

Forgive me if I missed the point...

(In reply to Bryce Nordgren from comment #23)
> Is the essential problem that including a notebook which works with the
> version of tornado shipped in RHEL would mean downgrading ipython to a
> version believed to be too old? 

Yes. The latest version of IPython Notebook that works with python-tornado 2.2.1 (the version in RHEL7) is 1.2.1.  2.4 needs 3.1, and 3.0 needs 4.0.

> No matter what version is included now, ipython (and many scientific
> libraries) evolves fast enough that three years from now it may not be
> compatible with then-current software. But I may not understand the EPEL
> philosophy regarding updates, as comment #22 mentions updating to a new
> major release version and I thought that was not the enterprise way...

That is certainly a concern.  And one reason that Till is suggesting waiting still further until 3.0 is out so that we can put that into EPEL7.  I have no idea myself if the jump from 2.4 to 3.0 is incompatible in any way for users.  Can anyone speak to this?  http://ipython.org/ipython-doc/dev/whatsnew/version3.html#backwards-incompatible-changes is the upstream docs, no idea how significant they are.

> Notebook is the majority of my use, if it were up to me, I'd package the
> version of Ipython available when the RHEL7 packages were frozen; so that
> notebook could be included. If I need newer ipython I'll pip install it or
> use Fedora. I would expect EL packages to have old versions.

I think that most of us fell that packaging ipython notebook 1.2.1 in EPEL7 is just not worth it.  Anyone who really wants to use it is going to want to use a newer version.  If that's not the case, we could revisit it.  Perhaps it's worth asking the EPEL users list?

At least for my own internal use, I'm planning on providing ipython-notebook in a COPR - https://copr.fedoraproject.org/coprs/orion/ipython/, and I think most of us feel this is the best way to provide ipython-notebook at the moment.

If RedHat ever bumps the version of python-tornado we may be able to ship a reasonably recent notebook in EPEL.

(In reply to Orion Poplawski from comment #24)
> (In reply to Bryce Nordgren from comment #23)
> That is certainly a concern.  And one reason that Till is suggesting waiting
> still further until 3.0 is out so that we can put that into EPEL7.  I have
> no idea myself if the jump from 2.4 to 3.0 is incompatible in any way for
> users.  Can anyone speak to this? 
> http://ipython.org/ipython-doc/dev/whatsnew/version3.html#backwards-
> incompatible-changes is the upstream docs, no idea how significant they are.

My main concern would be the notebook format changing, due to the fact that I couldn't recklessly move my code around anymore, but if notebook isn't included I don't have a problem with it.

> > Notebook is the majority of my use, if it were up to me, I'd package the
> > version of Ipython available when the RHEL7 packages were frozen; so that
> > notebook could be included. If I need newer ipython I'll pip install it or
> > use Fedora. I would expect EL packages to have old versions.
> 
> I think that most of us fell that packaging ipython notebook 1.2.1 in EPEL7
> is just not worth it.  Anyone who really wants to use it is going to want to
> use a newer version.  If that's not the case, we could revisit it.  Perhaps
> it's worth asking the EPEL users list?

That may be true. I use either a notebook environment or the regular python command line, skipping over ipython CLI. I could just be old and set in my ways. Notebook offers visualization over HTTP, which lets me fiddle with terabytes of data in my data center from my couch at home with a lousy DSL.

Perhaps the effort not wasted on notebook could be spent finishing out the "SciPy stack" in EPEL [1]. At least that way, library code could run in batch mode. You power my Cray via RocksClusters.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1197264

3.0 is released, so we should start taking a look at packaging that.

Sole response to my question on the ipython list, from Thomas Kluyver:

I would package it without the notebook. We're already not supporting 1.x releases, and even if you got 3.0 in, it will be out of date in a fraction of the lifetime of a RHEL release. I'd rather people who want the notebook be forced to install it another way than get an ancient version.

which I think reflects my sentiment as well.  If I don't hear any objections I'll get this pushed soon.

EPEL7 ipython 3.0 no-notebook scratch build:
koji.fedoraproject.org/koji/taskinfo?taskID=9123048

And a new one that requires python-mistune:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9133506

Just a heads up - nbconvert for both 2.4.1 and 3.0.0 makes use of latex's adjustbox.sty.  Unfortunately, EL7's texlive does not provide that, see https://bugzilla.redhat.com/show_bug.cgi?id=1198299 so that won't work.

ipython-3.1.0-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/ipython-3.1.0-2.el7

ipython-3.1.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository.

ipython-3.1.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository.