Example code using all_reference_compositions() may fail

[tectoni]

Example code from the pyrolite documentation website using the method all_reference_compositions() failed with Error:

Traceback (most recent call last):
  File "./example.py", line 14, in <module>
    for name, ref in list(all_reference_compositions().items())[::2]:
  File "/Users/myhomedir/opt/anaconda3/lib/python3.9/site-packages/pyrolite/geochem/norm/__init__.py", line 158, in all_reference_compositions
    for r in db.table().all():
TypeError: table() missing 1 required positional argument: 'name'

A suggested solution to the issue could be to explicitly give the name of the default table. Replace line 158 in __init__.py by for r in db.table("_default"):

Environment:

• OS: macOS 11.6.1
• Python Version 3.9
• Pyrolite Version 0.3.1

Additional Context A similar issue was earlier described by a user on GITTER pyrolite/community at 10/10/2020 (Lucy Mathieson).

[morganjwilliams]

Hey @tectoni! The file pyrolite/geochem/norm/__init__.py hasn't existed since pyrolite v0.2.3; I suspect you have an outdated installation of pyrolite, but a newer version of tinydb (which is what pyrolite is using to keep a table of reference compositions) - and that's where the conflict pops up. For the moment all looks OK in the test suites.

Perhaps try a reinstall/update of pyrolite or different environment, and that should clear up the issue.

[tectoni]

Hi @morganjwilliams! Thanks for the quick answer! It seems to be still included in pip. I did

pip uninstall pyrolite
pip install pyrolite

and pip tells me: Successfully installed pyrolite-0.3.1

I checked everything and it is still in the new installed 0.3.1. I will replace it with the latest version on github. cheers peter

[aReaSa]

+1 It is not happening whatever I tried. Can someone help me out, too? @morganjwilliams @tectoni

[morganjwilliams]

Hey @aReaSa, can you confirm what version of pyrolite you have installed? Note that newer versions aren't expected to work with Python 3.5 (current supported/tested versions are 3.7-3.9, 3.10 won't be far off and I'd expect minimal to no problems there). What I suspect may be happening is that you're getting the last pyrolite version which explicitly supported these versions of Python (likely 0.2.3 for Python 3.5, potentially all the way back to 0.0.12 for Python 3.10). I've added a test suite for Python 3.10 to the continuous integration workflow, and will let you know how it goes.

[morganjwilliams]

Can confirm that at least the latest pyrolite (v0.3.2) should run fine on Python 3.10 (passing test suite here).

[aReaSa]

@morganjwilliams first of all, thank you so much for your interest. However, the news are not good for me. Second of all, I'd like to report that I having three different pc at home (one is ubuntu) and something is wrong. Maybe the all installation proceses I do is wrong or something else? But so far, we could not figure it.

[morganjwilliams]

@aReaSa other things that could be interfering include having multiple versions of Python (common on Linux, Mac, sometimes occurs on Windows depending on how you install things), and for operations from terminals in Windows sometimes you'll need to close the terminal, start another and run from there.

pip --version should point you to both the version of pip and the location of pip using your terminal there, which will highlight if you may be working across different Python installations (e.g. installed into a 'system' Python or an older/first installation which isn't the Python 3.10.5 installation you're using in IDLE). If this is the case, you can use the extended version of the call to the correct pip to make sure you're installing to the right distribution: C:\<path_to_correct_python_installation_>\python.exe -m pip install pyrolite==0.3.2. Alternatively, you could do so inside IDLE (although, probably not the recommended way of working) using import sys; import subprocess; subprocess.check_call([sys.executable, '-m', 'pip', 'install', 'pyrolite==0.3.2']).

As a bit of an aside, using an Anaconda distribution coupled with creating (conda) 'environments' for different projects has worked pretty well for me, and might help with some of these types of issues in the future, if that's an option for you.

For the moment I don't think there's an inherent problem with the package, but I'll leave this thread open for now until we can determine what might be a good addition to the installation documentation around these types of issues.

[aReaSa]

I have fixed by replacing line 158 in init.py the

for r in db.table.all():

To

for r in db.all():

I don't know how I made it but it worked.

@morganjwilliams for your information

[morganjwilliams]

With a new version and explicit support for Python 3.10-3.11, I'm hoping this one is now solved.

[morganjwilliams]

Hey @tectoni and @aReaSa, after curiously running into this myself recently, it looks to have been an issue with old files being included specifically in the built binary wheel uploaded to PyPI (which generally would be avoided through installing either the source distribution or directly from GitHub). This one was a bit cryptic and certainly confused me for a bit, but I hope it's now a thing of the past - apologies I hadn't worked this out sooner!