scipy: update to v1.15.2 #3136
scipy: update to v1.15.2 #3136
Conversation
|
SDL does not builds with ndk CC: @misl6 |
|
Will continue working on the SDL3 recipes this weekend, however we are going to support both SDL2 and SDL3 for a long time, as only Kivy 3.0.0 will support SDL3, and will not be ready quite soon. Maybe we can use NDK 27 only for some specific recipes? (or a previous one for SDL2) |
|
Just saw fixed was also pushed for SDL2, so bumped version to include that fix. :) |
T-Dynamos
force-pushed
the
scipy_update
branch
2 times, most recently
from
5e09b20 to
48a215a
Compare
There was a problem hiding this comment.
Impressive work so far!
Thanks for picking this up too @T-Dynamos 🙏
Maybe it's a good time to rebase it since SDL3 (#3125) was merged
| # if 'version' is specified, do a shallow clone | ||
| if self.version: | ||
| ensure_dir(target) | ||
| with current_directory(target): | ||
| shprint(sh.git, 'init') | ||
| shprint(sh.git, 'remote', 'add', 'origin', url) | ||
| else: | ||
| shprint(sh.git, 'clone', '--recursive', url, target) | ||
| with current_directory(target): | ||
| if self.version: | ||
| shprint(sh.git, 'fetch', '--tags', '--depth', '1') | ||
| shprint(sh.git, 'checkout', self.version) | ||
| branch = sh.git('branch', '--show-current') | ||
| if branch: | ||
| shprint(sh.git, 'pull') | ||
| shprint(sh.git, 'pull', '--recurse-submodules') | ||
| shprint(sh.git, 'submodule', 'update', '--recursive', '--init', '--depth', '1') | ||
|
|
||
| shprint( | ||
| sh.git, | ||
| 'clone', | ||
| '--branch', | ||
| self.version, | ||
| '--depth', | ||
| '1', | ||
| '--recurse-submodules', | ||
| '--shallow-submodules', | ||
| url, | ||
| target, | ||
| ) | ||
|
|
There was a problem hiding this comment.
While I like that we simplify code, I'm wondering if we didn't break the feature of checking out a git hash as we removed that line shprint(sh.git, 'checkout', self.version)
Also this change seems out of scope of this PR. Maybe we can open a dedicated PR for it and try if git commit hash are still supported
| class GFortranRecipe(Recipe): | ||
| # flang support in NDK by @licy183 (on github) | ||
| name = "fortran" | ||
| toolchain_ver = 0 | ||
| url = "https://github.com/licy183/ndk-toolchain-clang-with-flang/releases/download/" | ||
|
|
||
| def match_sha256(self, file_path, expected_hash): | ||
| sha256 = hashlib.sha256() | ||
| with open(file_path, "rb") as f: | ||
| for chunk in iter(lambda: f.read(8192), b""): | ||
| sha256.update(chunk) | ||
| file_hash = sha256.hexdigest() | ||
| return file_hash == expected_hash |
There was a problem hiding this comment.
I'm not sure how to feel about downloading a binary from a non-official source.
It's indeed very convenient to have the option, but maybe we can have an extra runtime warning or yes/no prompt for the user before moving forward with the recipe download/install, what do you think?
I'm not sure what's the best approach, we don't want the implementation to be cumbersome of course, but we still want to protect our users.
Or maybe none of this, but enforce hash verification for this recipe, with a code comment to future developer explaining that the recipe should always come with the hash check (assuming due diligence was done by the recipe maintainer upfront for spot checking a version before offering it).
I'm open to suggestion and debate the options
Closes #3116
Cons:
Extra Notes:
Removes need to use
LEGACY_NDKas it uses fortran from https://github.com/termux/ndk-toolchain-clang-with-flang.