Tags: jetify-com/devbox
Tags
In the mysql/mariadb templates, set MYSQL_UNIX_PORT to a hardcoded sh… …ort path (#2523) ..rather than plugin's project-relative path, to avoid triggering 'The socket file path is too long (> 107)' error on start. Also specify the (blank) password in 'test_db_setup'. Fixes #2521 ## How was it tested? Per the description in #2521, after this change `mysqld` should come up in a >107 length path, e.g.: ``` cd ~/src/github.com/jetify-com/devbox/examples/databases/mysql devbox services up -b tail -1 .devbox/compose.log # This shows the socket path, which should now be /tmp/devbox/mariadb/run/mysql.sock devbox run mysql -u root -p # Blank password - connects ``` Note: I have patched mysql and mariadb because they are essentially the same. However whereas `mysql` respects the `MYSQL_UNIX_PORT` env variable, `mysql` from the mariadb package does not (logged as #2522), so the last step of this code fails: ``` cd ~/src/github.com/jetify-com/devbox/examples/databases/mariadb devbox services up -b tail -1 .devbox/compose.log # This shows the socket path, which should now be /tmp/devbox/mariadb/run/mysql.sock devbox run mysql -u root -p # ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2) ``` Aside from testing, this mariadb bug is irrelevant to this patch. I just thought I'd mention it. --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: John Lago <750845+Lagoja@users.noreply.github.com> Co-authored-by: Artem Klevtsov <a.a.klevtsov@gmail.com> Co-authored-by: Greg Curtis <greg.curtis@jetify.com> Co-authored-by: Daniel Loreto <279789+loreto@users.noreply.github.com> Co-authored-by: Mike Landau <mikeland86@gmail.com> Co-authored-by: John Lago <750845+Lagoja@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Will Brennan <will@moondev.co.uk>
[deps] Fix a few more dependabot issues (#2552) ## Summary ## How was it tested? ## Community Contribution License All community contributions in this pull request are licensed to the project maintainers under the terms of the [Apache 2 License](https://www.apache.org/licenses/LICENSE-2.0). By creating this pull request, I represent that I have the right to license the contributions to the project maintainers under the Apache 2 License as stated in the [Community Contribution License](https://github.com/jetify-com/opensource/blob/main/CONTRIBUTING.md#community-contribution-license). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Chores** - Updated several third-party dependency versions to enhance overall stability, performance, and security. - Updated the vendor hash to reflect changes in dependencies. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
fix: disable poetry plugin output (#2482) ## Summary When using poetry, with the suggested `init_hook` from the docs: ``` { "packages": [ "python3", "poetry@1.8" // notice I am using poetry 1.8, the poetry shell command is not part of poetry version 2.0 ], "shell": { "init_hook": "poetry shell" } } ``` and running `devbox shell`, while the poetry env is being loaded, it generates this log: `Using virtualenv: /home/fotiadis/src/work/trumo/services/tc_gateway_consumer/.venv` This can be problematic to users instant prompt like the very famous zsh theme [powerlevel10k](https://github.com/romkatv/powerlevel10k) By adding the `--quiet` flag this solves the problem ### What about poetry 2.0? poetry 2.0 has removed the `poetry shell` (the functionality still exists if you download a plugin). The new way to achieve the same behavior according to [the docs](https://python-poetry.org/docs/managing-environments/#activating-the-environment) is: `eval $(poetry env activate)` This change doesn't impact either major versions of poetry, and it will continue to work as normal ## How was it tested? By disabling the current poetry plugin, and creating a new one that is the exact copy, just with the flag on
fix: disable poetry plugin output (#2482) ## Summary When using poetry, with the suggested `init_hook` from the docs: ``` { "packages": [ "python3", "poetry@1.8" // notice I am using poetry 1.8, the poetry shell command is not part of poetry version 2.0 ], "shell": { "init_hook": "poetry shell" } } ``` and running `devbox shell`, while the poetry env is being loaded, it generates this log: `Using virtualenv: /home/fotiadis/src/work/trumo/services/tc_gateway_consumer/.venv` This can be problematic to users instant prompt like the very famous zsh theme [powerlevel10k](https://github.com/romkatv/powerlevel10k) By adding the `--quiet` flag this solves the problem ### What about poetry 2.0? poetry 2.0 has removed the `poetry shell` (the functionality still exists if you download a plugin). The new way to achieve the same behavior according to [the docs](https://python-poetry.org/docs/managing-environments/#activating-the-environment) is: `eval $(poetry env activate)` This change doesn't impact either major versions of poetry, and it will continue to work as normal ## How was it tested? By disabling the current poetry plugin, and creating a new one that is the exact copy, just with the flag on
patchpkg: fix system CUDA lib search (#2507) As part of the auto-patching for CUDA, devbox searches for the system's libcuda (installed by the driver) and adds it to the Nix store. This fixes a couple of bugs with that search process: - When creating the soname links, the base name of the path to libcuda wasn't being used. This would lead to creating symlinks like "lib/libcuda.so.1", which would fail because a lib subdirectory didn't exist. - Ensure the `src` attribute is set in the patch flake so that devbox knows the path the flake source (which contains the copied libcuda) at build time.
[docs] add note about github plugin cache env-var (#2479) ## Summary ## How was it tested?
[docs] add note about github plugin cache env-var (#2479) ## Summary ## How was it tested?
PreviousNext