Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to Launch allzpark On New OSX Python 3.9 Install #128

Open
mstreatfield opened this issue Nov 10, 2020 · 4 comments
Open

Unable to Launch allzpark On New OSX Python 3.9 Install #128

mstreatfield opened this issue Nov 10, 2020 · 4 comments
Labels
bug Something isn't working

Comments

@mstreatfield
Copy link

Hello,

After following the quickstart for bleeding-rez and quickstart for allzpark, I get the following error on OSX when trying to launch allzpark for the first time.

==============================
 allzpark (1.3.41)
==============================
- Loading demo..ok - 0.00
  - /usr/local/lib/python3.9/site-packages/allzparkdemo/rezconfig.py
  - /usr/local/lib/python3.9/site-packages/allzparkdemo/allzparkconfig.py
- Loading Rez.. (2.40.5) - ok 0.10
- Loading Qt.. (PySide2 - 5.15.1) - ok 0.11
- Loading allzpark.. fail
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/allzpark/cli.py", line 99, in timings
    yield message
  File "/usr/local/lib/python3.9/site-packages/allzpark/cli.py", line 245, in main
    from . import view, control, resources, util
  File "/usr/local/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 146, in _import
    return original_import(name, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/allzpark/view.py", line 13, in <module>
    from . import resources as res, dock, model
  File "/usr/local/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 146, in _import
    return original_import(name, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/allzpark/dock.py", line 12, in <module>
    from . import resources as res, model, delegates, util
  File "/usr/local/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 146, in _import
    return original_import(name, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/allzpark/model.py", line 41, in <module>
    from . import allzparkconfig, util, resources as res
  File "/usr/local/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 146, in _import
    return original_import(name, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/allzpark/util.py", line 15, in <module>
    _timer = time.time if os.name == "nt" else time.clock
AttributeError: module 'time' has no attribute 'clock'

Python has been installed using brew to replace the system python:

Python 3.9.0 (default, Oct 27 2020, 14:15:17)
[Clang 12.0.0 (clang-1200.0.32.21)]

And I'm using the latest version of bleeding-rez:

bleeding-rez 2.40.5

It looks like time.clock was deprecated around Python 3.3 and then removed in 3.8 due to platform-dependent behaviour. Updating to using time.time instead is enough to move past the error and have allzpark start as expected. The PEP-418 suggests using time.perf_counter might be preferable.

Sounds like it might be simple to resolve - unfortunately, I'm not able to make a pull request for a fix at the moment.

Mark.

@davidlatwe
Copy link
Collaborator

Oops, that has been fixed in #121 (commit 99c7de7), but not yet released. Could you directly pull current master branch and have a test ?

@mottosso mottosso added the bug Something isn't working label Nov 10, 2020
@davidlatwe
Copy link
Collaborator

Okay, I just made a release 1.3.67, wait a few minutes and you could pip install -U allzpark !

The PEP-418 suggests using time.perf_counter might be preferable.

Hmmm, the replacment I used was process_time, looks like using perf_counter is better indeed.

@mstreatfield
Copy link
Author

I pip installed the latest version and it's working perfectly now. Thank you for the quick turnaround, I appreciate it!

My read of the documentation is that perf_counter will be more accurate for time deltas, although perhaps this isn't needed if what is being measured is application/module load time.

@davidlatwe
Copy link
Collaborator

Thanks for confirm !

Regarding perf_counter, yeah I agree. Didn't think much at the time being, was trying to get pass CI testing and thought it doesn't matter much for our use case.

Anyway, PR is welcome ! (not limited to this issue of course :P)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants