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

Is this project still maintained? #7

Open
g3k0 opened this issue Apr 28, 2024 · 0 comments
Open

Is this project still maintained? #7

g3k0 opened this issue Apr 28, 2024 · 0 comments
Labels
Type: Question ❔ Question about implementation or some technical aspect

Comments

@g3k0
Copy link

g3k0 commented Apr 28, 2024

Question

Is this project still maintained?

Further Information

This library seems to offer exactly what I need for one of my projects.
Installing the lib from pip I encounter some errors:

Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [80 lines of output]
      Running from numpy source directory.
      <string>:461: UserWarning: Unrecognized setuptools command, proceeding with generating Cython sources and expanding templates
      /tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py:75: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
        required_version = LooseVersion('0.29.14')
      /tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py:77: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
        if LooseVersion(cython_version) < required_version:
      performance hint: _common.pyx:261:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:285:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:308:50: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:411:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:448:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:490:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:573:36: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:577:36: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:581:36: Exception check after calling 'f2' will always require the GIL to be acquired. Declare 'f2' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:585:36: Exception check after calling 'f3' will always require the GIL to be acquired. Declare 'f3' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:617:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:652:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:687:63: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:727:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:756:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:874:40: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:878:40: Exception check after calling 'fd' will always require the GIL to be acquired. Declare 'fd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:882:41: Exception check after calling 'fdd' will always require the GIL to be acquired. Declare 'fdd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:887:40: Exception check after calling 'fi' will always require the GIL to be acquired. Declare 'fi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:891:41: Exception check after calling 'fdi' will always require the GIL to be acquired. Declare 'fdi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:895:38: Exception check after calling 'fiii' will always require the GIL to be acquired. Declare 'fiii' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:930:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: _common.pyx:972:32: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      
      Error compiling Cython file:
      ------------------------------------------------------------
      ...
          def __init__(self, seed=None):
              BitGenerator.__init__(self, seed)
              self.rng_state.pcg_state = &self.pcg64_random_state
      
              self._bitgen.state = <void *>&self.rng_state
              self._bitgen.next_uint64 = &pcg64_uint64
                                         ^
      ------------------------------------------------------------
      
      _pcg64.pyx:113:35: Cannot assign type 'uint64_t (*)(void *) except? -1 nogil' to 'uint64_t (*)(void *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to the type of the value being assigned.
      Processing numpy/random/_bounded_integers.pxd.in
      Processing numpy/random/_common.pyx
      Processing numpy/random/_pcg64.pyx
      Traceback (most recent call last):
        File "/tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py", line 238, in <module>
          main()
        File "/tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py", line 234, in main
          find_process_files(root_dir)
        File "/tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py", line 225, in find_process_files
          process(root_dir, fromfile, tofile, function, hash_db)
        File "/tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py", line 191, in process
          processor_function(fromfile, tofile)
        File "/tmp/pip-install-hetw5y7g/numpy_5446cc5f83b34d51a57a903d21e3b078/tools/cythonize.py", line 80, in process_pyx
          subprocess.check_call(
        File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command '['/home/christian/Studio/crypto-py/venv/bin/python3', '-m', 'cython', '-3', '--fast-fail', '-o', '_pcg64.c', '_pcg64.pyx']' returned non-zero exit status 1.
      Cythonizing sources
      Traceback (most recent call last):
        File "/home/christian/Studio/crypto-py/venv/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/home/christian/Studio/crypto-py/venv/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/christian/Studio/crypto-py/venv/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 149, in prepare_metadata_for_build_wheel
          return hook(metadata_directory, config_settings)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/tmp/pip-build-env-0c2ziobe/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 366, in prepare_metadata_for_build_wheel
          self.run_setup()
        File "/tmp/pip-build-env-0c2ziobe/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 487, in run_setup
          super().run_setup(setup_script=setup_script)
        File "/tmp/pip-build-env-0c2ziobe/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 311, in run_setup
          exec(code, locals())
        File "<string>", line 488, in <module>
        File "<string>", line 469, in setup_package
        File "<string>", line 275, in generate_cython
      RuntimeError: Running cythonize failed!
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

Since the last commit is about 4 years ago, I would like to know if this project is still active.

Screenshots

If applicable, add screenshots to help explain your question.

System Information

  • OS: Mx Linux
  • OS Version: 23.2
  • Language Version: Python 3.11.2
  • Package Manager Version: pip 23.0.1

Additional Context

@g3k0 g3k0 added the Type: Question ❔ Question about implementation or some technical aspect label Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Question ❔ Question about implementation or some technical aspect
Projects
None yet
Development

No branches or pull requests

1 participant