Feature #23310
closedinstall-dev-tools has option to install Ruby and Python from source
Description
While working on #23000, I learned that bundle install will resolve gems for the specific version of Ruby that you're running. This means if we always ran bundle install with the oldest version of Ruby we support, we could help prevent situations like upgrading to too-new versions of gems.
Similarly, for a while in my development environment I've installed the oldest version of Python we support, and use it for running Arvados tests, to help ensure I don't accidentally use too-new features. For example, that's how I found 636a597c51c0ddbe204efc06fbea78fbdb329b9d.
Add a boolean flag to install-dev-tools. When set, it installs the oldest versions of Ruby and Python we support from source for development. Install under /opt and add symlinks to /usr/local/bin like we do for other tools like NodeJS. If necessary, extend the development bash profile file to make sure this directory comes first in $PATH.
When unset, install these tools from packages as now. We want to retain the ability to test against the packaged versions that our users will actually deploy with, and this accomplishes that goal. The idea is that developers installing their own development environments will install from source, while we'll install from packages when setting up test images etc.
Files
Updated by Brett Smith 4 months ago
- Target version set to Development 2025-12-10
- Assigned To set to Brett Smith
- Status changed from New to In Progress
Updated by Brett Smith 4 months ago
- File 23310test.log.xz 23310test.log.xz added
23310-dev-from-source @ 8f0553e758a6306b4767285d22715fc15d63252e - developer-run-tests: #4962
- All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
- Yes
- This revealed a couple minor bugs in
run-tests.shthat I also fixed.
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- #23347
- Code is tested and passing, both automated and manual, what manual testing was done is described.
- Using the new playbook, I built a new Debian 12 VM and ran the tests from scratch. On that system, I ran
mkdir ~/tmp && build/run-tests.sh --temp ~/tmp --only install && build/run-tests.sh --temp ~/tmp --skip sanity --skip install. See the attached log. Thelib/controller/localdbtests are being fixed in #23325. Thelib/crunchruntest is because of the way my VM is configured on the host, it's not a problem with any software.
- Using the new playbook, I built a new Debian 12 VM and ran the tests from scratch. On that system, I ran
- Tested code incorporates recent main branch changes.
- Yes
- New or changed UI/UX and has gotten feedback from stakeholders.
- N/A
- Documentation has been updated.
- After this merges I can document
arvados_dev_from_pkgson Hacking_prerequisites. That probably makes the most sense.
- After this merges I can document
- Behaves appropriately at the intended scale (describe intended scale).
- No change beyond the overhead of building these runtimes. The playbook is smart enough to avoid redundant builds, while building new versions when needed.
- Considered backwards and forwards compatibility issues between client and server.
- N/A
- Follows our coding standards and GUI style guidelines.
- N/A, no relevant style guide
Updated by Brett Smith 4 months ago
Brett Smith wrote in #note-5:
- After this merges I can document
arvados_dev_from_pkgson Hacking_prerequisites. That probably makes the most sense.
This is done along with some general sprucing up at https://dev.arvados.org/projects/arvados/wiki/Hacking_prerequisites/90
Updated by Brett Smith 3 months ago
- Related to Feature #23373: install-dev-tools.yml can set up a test environment on Debian 13 added