Mu: requirements.txt misses some required packages

[kzar]

I found I also needed to install QScintilla and PyQt5 before mu would run. Perhaps those should be included in requirements.txt?

[inglesp]

Hi @kzar -- are PyQt5 and QScintilla pip-installable now? Your issue suggests they might be. They weren't when we first worked on packaging mu last year.

[kzar]

Yep I think so, well I was able to install them with Pip anyway. (Pip for Python 3 as provided in Debian stretch.)

[inglesp]

That's quite exciting, and it might make our whole packaging process a bit more streamlined. I'm testing this out now.

[willingc]

Interested in the results of #121. We use Qt in the Jupyter Qt Console (https://qtconsole.readthedocs.io/en/latest/installation.html).

@takluyver, do you have additional insights on Qt and pip?

[takluyver]

PyQt5 is now pip installable for Python 3.5, so we could express a dependency on it for the Qt console. I think the tricky point for us is that we depend on one of PyQt5 _or_ PyQt4 _or_ PySide, and there's no great mechanism to specify that, even if wheels were available in all cases.

[carlosperate]

I think the tricky point for us is that we depend on one of PyQt5 or PyQt4 or PySide, and there's no great mechanism to specify that, even if wheels were available in all cases.

This is also a problem when trying to package into a single executable, as the mechanism used to detect available libraries uses __import__ and that doesn't work with PyInstaller, so the workaround can be quite ugly: https://github.com/ntoll/mu/commit/c3bd2a8ec2a26798c2f1643d078b25ad0f1b59b8#diff-5ff4c2f00727c388514182dd8570e7d1R33

[takluyver]

All the freeze tools' dependency detection machinery is terrible, in my experience. Glyph has spoken and written about this as well. Application packaging should use an explicit list of requirements, as I do in Pynsist.

[carlosperate]

In this case is not about PyInstaller's ability to detect dependencies, but whatever mechanism they use to import their packaged modules does not seem to work when calling __import__ directly. qt_loaders.has_binding() uses this method of importing to check if an specific module is available, so it fails to detect the module during runtime even if it has been packaged with the application.

Btw @takluyver, do you have any links about Glyph's articles about this? Should definitely make for an interesting read.

[takluyver]

I can't find a written article just now, but here's his talk at PyCon this year:
https://www.youtube.com/watch?v=5BqAeN-F9Qs

[askvictor]

I successfully installed pyqt5 and QScintilla on Windows, if that helps.

Can I suggest choosing one of the possibilities and sticking with it? It will probably make dev easier having to support fewer permutations. And people who know what they're doing can install the others anyway.

[carlosperate]

I successfully installed pyqt5 and QScintilla on Windows, if that helps.

@askvictor Was that using pip?

[askvictor]

@carlosperate using pycharm's package installer, but I'm pretty sure that's just pip under the hood.

[carlosperate]

The only thing is that these pip packages are only for Python 3.5. So if it fails we should still include some information to direct devs to an alternative installation methods.
Keep in mind that, ideally, we should keep this project simple enough so that as new developers progress, they could then edit and play with the Mu code itself. And in that sense, the first few steps of installing all these types of dependencies can be a barrier of entry for novice users.

[carlosperate]

Some general update to using the PyPI PyQt5 and Qscintilla packages.

Linux: Currently the Qscintilla wheel links to a version of glibc that is too "new" to be considered compatible enough with older distros (https://www.riverbankcomputing.com/pipermail/qscintilla/2016-November/001173.html).

Windows: Works fine for user installations. It also builds ok with PyInstaller as long as additional hooks are added, however if built in a version of Windows with the CRT it might make the self-contained executable dependent on it, which is a problem that still needs to be investigated.

macOS: Works fine for user installations. It builds ok with PyInstaller if using built-in hooks from their master repository (not yet included in the latest release, which is quite old).

[ntoll]

This is fixed since Qt / pip / Python support is much better now. Closing. Thanks for the contributions everyone..!