Open mivade opened 7 years ago
Hi @mivade. Please, have a look to the last entry of the FAQ in the ViTables website and tell me if the suggested solution works for you. I hope it will.
I was able to install it by commenting out the PyQt requirement in setup.py
, but considering that many users of ViTables are likely using miniconda/Anaconda already, I think this should be handled more gracefully.
For what it's worth, I also had issues with the conda-forge package (which is why I tried installing from source in the first place).
Do you think a new release is required? Right now I've no new features, just some refactored code. And I'm not sure about how to deal with the PyQt5 issue. Do you think I should simply remove the requirement and print a message if the dependency is not satisfied?
I don't think a new release is required (although the PyPI package is considerably out of date). Failing with a message with hints about how to install PyQt5 seems sufficient to me.
Unfortunately the PyPI problem seems difficult to fix. Somebody (not me) published the 2.1 version when it was realeased and now I've no permissions for uploading the package to PyPI. I've asked for help to PyPI support team with no luck. If you have some idea I'll be glad to hear it.
Hm. From what I understand the only way to get package ownership is to get the existing owner to give it to you. How annoying.
Supposedly you can use this to request ownership transfer.
Yes, but as I told you the support guys are not very responsive. Anyway, thanks for your bug report and for your suggestions :-) I'll try to fix the problems with packages ASAP.
My preference for this problem would be for ContinuumIO/anaconda-issues#1554 to address this. Because that is where the PyPi name is abused. Breaking pip
dependencies is not a good omen.
If however it is deemed preferable to remove hard dependency, substituting it with one (or 2 for conda/pip packages) optional dependencies would at least work.
The optimal workaround is to use a pep508 environment-marker for anaconda. [Edit:] eg this is promising:https://stackoverflow.com/a/21282816
Optional dependencies does seem like a reasonable way to handle this. I agree though that fixing the upstream issue with conda would be optimal.
Hi @ankostis, nice to hear from you again! Do you mean I should include in setup.py something like this?
setup(
install_requires=[
# ...
],
extra_requires={
'"Anaconda" not in sys.version': [ 'PyQt5>=5.5.1']
]
}
)
Not sure about the syntax in the above example. Also I've not found a sys_version marker in the PEP 508.
Ran into this problem today. The FAQ was pretty confusing. What worked for me:
conda install vitables -c conda-forge
conda remove vitables
edit Anaconda3\pkgs\vitables-3.0.0-0\Lib\site-packages\ViTables-3.0.0.egg-info\requires.txt
to remove the PyQt5 line
conda install vitables
Now vitables
runs the app.
Maybe make the PyQt5 requirement optional and print a warning to stdout about how to install it.
@uvemas you are right!
There is no way to detect Anaconda from environment markers (results of the methods in platform
package).
A plain extra_requires to PyQt5
is the only alternative i can see.
And it would burden the pip
users, although conda is the bad citizen here :-(
Well, this is a possible workaround I've found. Please, let me know if you see some serious problem with it:
# setup.py
install_requires = ['qtpy (>=1.2.1)',
'numpy (>=1.4.1)',
'numexpr (>=2.0)',
'tables (>=3.0)'
]
if "CONDA_PREFIX" not in os.environ:
install_requires.append('PyQt5 (>=5.5.1)')
setup(name='ViTables',
...
install_requires=install_requires,
...
)
I've tested it installing a ViTables tarball and it works just fine.
That's straight forward and simple. The only drawbacks that i can think of are minor points, related to pre-packaged wheels:
pip install
still will not work),Maybe it is easier and sufficient to get vitables into the conda repository?
Yes, I'm aware of the drawbacks but as you say they are minor. Now my question is: can we have this workaround included in a new conda-forge package without publishing a new vitables release?
Sorry David, I didn't see your post. Getting ViTables on the conda repo does not depend on me. Currently ViTables is in the conda-forge channel which I suppose is run by volunteers. And I don't know how this channel works internally so I'm not sure how to get the workaround included in a new package.
Ok, I've asked the package maintainer how to proceed in order to build a new conda-forge package with the new setup.py. Now we have to wait for his answer.
@uvemas Why does vitables depend on PyQt5 in the first place when all the calls are handled by QtPy?
The feature has already been introduced in https://github.com/uvemas/ViTables/issues/62 and https://github.com/uvemas/ViTables/pull/66 .
I uninstalled PyQt5 and removed the entry in egg-info/requires.txt. And vitables runs well with PyQt4.
Can't we just fix the missing-dependency-issue by removing PyQt5 (>=5.5.1)
requirement from setup.py
? I have no issues with that (using Anaconda/Miniconda). If the requirement is missing the user will figure out and install the missing package. The current state is even more dissatisfying because it requires to edit the setup.py
.
There will be no final/good solutions, only practical solutions.
In version 3.0.2 the PyQt5 dependency is added conditionally (checking the CONDA_PREFIX environment variable). Now it seems that, if conda-forge package installation fails, ViTables can be installed just fine from PyPI:
(base) conda create --name vitables pytables pyqt
(base) conda activate vitables
(vitables) pip install ViTables
or downloading the source package:
(vitables) python setup.py install
Hope it helps.
In version 3.0.2 the PyQt5 dependency is added conditionally (checking the CONDA_PREFIX environment variable). Now it seems that, if conda-forge package installation fails, ViTables can be installed just fine from PyPI:
(base) conda create --name vitables pytables pyqt
(base) conda activate vitables
(vitables) pip install ViTables
or downloading the source package:
(vitables) python setup.py install
Hope it helps.
Thank you for your effort on this issue.
This is not a solution, because there is way more use cases beyond conda. Checking the CONDA_PREFIX environment variable is an unnecessary complexity.
I encountered the same issue yesterday. After installing ViTables
via pip install vitables
, I couldn't restart my Spyder
IDE. So I had to reinstall Anaconda
today.
Any way to install ViTables
as a standalone application? For example, it would be nice to provide some pre-built binary packages in the release page.
Hi @myd7349 , I've been able to reproduce the problem only when installing the ViTables wheel from Christoph Gohlke's website. In that case Spyder and Anaconda Navigator both refuse to start. I've managed to fix it by removing (via pip uninstall) all PyQt packages installed when installing the wheel (PyQt5-sip, PyQt5-Qt5 and PyQt5) and reinstalling PyQt5 with
conda install -c anaconda pyqt
Anyway it seems that installing ViTables in current Anaconda version is more difficult than in previous versions and the standard installation way (from the conde-forge channel) fails. The alternative way described in the FAQ still works for me. And you can always try to install from sources.
Running
python setup.py install
yields the following:This is despite having PyQt 5.6.0 installed:
PyQt requirements from PyPI are generally rather tricky. A better approach would be to try to import it and tell the user how to obtain it if it's not found.