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

[For discussion] Why not loading the programmer pip packages statically, like all the other pip packages? #532

Closed
zapta opened this issue Jan 10, 2025 · 7 comments

Comments

@zapta
Copy link
Collaborator

zapta commented Jan 10, 2025

apio has a list of pip packages that it loads (or asks the user to load) dynamically upon programmer demand.

"blackiceprog": ">=2.0.0,<3.0.0",

Why not loading those pip packages statically like all the other pip package dependencies of apio?

Motivation: Code simplicity, avoiding user hassle, and early detection of broken packages (for example, the 'litterbox' package can't be installed on mac osx).

@Obijuan , @cavearr, any thoughts?

@cavearr
Copy link
Member

cavearr commented Jan 10, 2025

I completely agree, along these lines I have proposed in another issue to create your own package of tinyprog and the rpds library for OSX (although I will put the issue in oss-cad-suite, I have been looking at the code in case I could send you the patch but I think it is going to be a limitation of the cross-compilation system that they have set up, since they build in a superb x86 docker and it gives me that for some reason that library is compiled as the host, next week I will have a linux x86 I will investigate by doing some tests to see if I can send you the issue with a solution included).

For my part, I would package and manage everything that we can control that does not include oss-cad-suite. At Icestudio I am preparing something similar with some dependencies that we have obsolete from node and js libraries that I am going to include statically outside of node to avoid deprecation messages and problems when updating node as well as to ensure that the projects will not disappear and leave Icestudio hanging.

@zapta
Copy link
Collaborator Author

zapta commented Jan 10, 2025

@cavearr, I will got ahead and change the packages import to be static.

What should we do about the pip 'litterbox' package which does not import on darwin? Can we drop support for this board since it doesn't work anyway, and it's limited to the platform linux_armv7 which we don't support.

"cat-board": {

/projects/tools-oss-cad-suite-dev/repo/scripts$ pip install litterbox
Collecting litterbox
  Using cached litterbox-0.2.2-py2.py3-none-any.whl
Collecting future>=0.15.0 (from litterbox)
  Using cached future-1.0.0-py3-none-any.whl.metadata (4.0 kB)
Collecting RPi.GPIO (from litterbox)
  Using cached RPi.GPIO-0.7.1.tar.gz (29 kB)
  Preparing metadata (setup.py) ... done
Requirement already satisfied: tqdm in /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages (from litterbox) (4.67.1)
Using cached future-1.0.0-py3-none-any.whl (491 kB)
Building wheels for collected packages: RPi.GPIO
  Building wheel for RPi.GPIO (setup.py) ... error
  error: subprocess-exited-with-error
  
  × python setup.py bdist_wheel did not run successfully.
  │ exit code: 1
  ╰─> [34 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build/lib.macosx-10.13-universal2-cpython-313/RPi
      copying RPi/__init__.py -> build/lib.macosx-10.13-universal2-cpython-313/RPi
      creating build/lib.macosx-10.13-universal2-cpython-313/RPi/GPIO
      copying RPi/GPIO/__init__.py -> build/lib.macosx-10.13-universal2-cpython-313/RPi/GPIO
      running build_ext
      building 'RPi._GPIO' extension
      creating build/temp.macosx-10.13-universal2-cpython-313/source
      clang -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -O3 -Wall -arch arm64 -arch x86_64 -I/Library/Frameworks/Python.framework/Versions/3.13/include/python3.13 -c source/c_gpio.c -o build/temp.macosx-10.13-universal2-cpython-313/source/c_gpio.o
      source/c_gpio.c:170:9: warning: cast to smaller integer type 'uint32_t' (aka 'unsigned int') from 'uint8_t *' (aka 'unsigned char *') [-Wpointer-to-int-cast]
          if ((uint32_t)gpio_mem % PAGE_SIZE)
              ^~~~~~~~~~~~~~~~~~
      source/c_gpio.c:171:34: warning: cast to smaller integer type 'uint32_t' (aka 'unsigned int') from 'uint8_t *' (aka 'unsigned char *') [-Wpointer-to-int-cast]
              gpio_mem += PAGE_SIZE - ((uint32_t)gpio_mem % PAGE_SIZE);
                                       ^~~~~~~~~~~~~~~~~~
      2 warnings generated.
      source/c_gpio.c:170:9: warning: cast to smaller integer type 'uint32_t' (aka 'unsigned int') from 'uint8_t *' (aka 'unsigned char *') [-Wpointer-to-int-cast]
          if ((uint32_t)gpio_mem % PAGE_SIZE)
              ^~~~~~~~~~~~~~~~~~
      source/c_gpio.c:171:34: warning: cast to smaller integer type 'uint32_t' (aka 'unsigned int') from 'uint8_t *' (aka 'unsigned char *') [-Wpointer-to-int-cast]
              gpio_mem += PAGE_SIZE - ((uint32_t)gpio_mem % PAGE_SIZE);
                                       ^~~~~~~~~~~~~~~~~~
      2 warnings generated.
      clang -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -O3 -Wall -arch arm64 -arch x86_64 -I/Library/Frameworks/Python.framework/Versions/3.13/include/python3.13 -c source/common.c -o build/temp.macosx-10.13-universal2-cpython-313/source/common.o
      clang -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -O3 -Wall -arch arm64 -arch x86_64 -I/Library/Frameworks/Python.framework/Versions/3.13/include/python3.13 -c source/constants.c -o build/temp.macosx-10.13-universal2-cpython-313/source/constants.o
      clang -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -O3 -Wall -arch arm64 -arch x86_64 -I/Library/Frameworks/Python.framework/Versions/3.13/include/python3.13 -c source/cpuinfo.c -o build/temp.macosx-10.13-universal2-cpython-313/source/cpuinfo.o
      clang -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -O3 -Wall -arch arm64 -arch x86_64 -I/Library/Frameworks/Python.framework/Versions/3.13/include/python3.13 -c source/event_gpio.c -o build/temp.macosx-10.13-universal2-cpython-313/source/event_gpio.o
      source/event_gpio.c:24:10: fatal error: 'sys/epoll.h' file not found
      #include <sys/epoll.h>
               ^~~~~~~~~~~~~
      1 error generated.
      error: command '/usr/bin/clang' failed with exit code 1
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for RPi.GPIO
  Running setup.py clean for RPi.GPIO
Failed to build RPi.GPIO
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (RPi.GPIO)

@cavearr
Copy link
Member

cavearr commented Jan 10, 2025

Hello @zapta!, could we have plates by architecture? I don't know if Apio can have boards supported only by certain architectures. If that were not the case, for me we could leave this board, I do not know it and I have no references to it but I have no news of any user who uses it.

I don't know if @Obijuan will need it or consider it important to maintain, if necessary I could try to compile it and generate our own package, but I think it doesn't make sense because a board appears dependent on an old Rpi board and I don't think it would take the effort. sense.

@zapta
Copy link
Collaborator Author

zapta commented Jan 11, 2025

Hi @cavearr, currently these two linux_arm are dead code and even if we will add support for the platform linux_arm, we will need to do coding to support properly partial paltform support, and to write testing for it, such that this is not just a matter of adding packages.

In general deadcode is a bad practice. It rots over time, makes maintance and testing more complex and confuses users.

How about if I will delete them now, and if the priority will arise we will add them back properly, since the code will still be in git.

@cavearr
Copy link
Member

cavearr commented Jan 11, 2025

i'm totally agree with you, for me go ahead.

@zapta
Copy link
Collaborator Author

zapta commented Jan 11, 2025

Thanks, will do.

zapta added a commit to zapta/apio_dev that referenced this issue Jan 11, 2025
… non supported platform linux_armv7l. Discussion here FPGAwars#532
@zapta
Copy link
Collaborator Author

zapta commented Jan 11, 2025

Done. Closing.

@zapta zapta closed this as completed Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants