Scraped latest definitions

[nodenv-bot]

• 22.11.0

[raygesualdo]

@minimum2scp @jasonkarns Do we know when this will be merged? This is blocking updating to latest v22 LTS via asdf.

[n-rodriguez]

@raygesualdo I don't know why but every release/PR takes several days to get merged 😢

[gnowland]

Protip: you don't need to wait for a node-build release and can start using the latest version in asdf immediately like so:

cd $ASDF_DIR/plugins/nodejs/.node-build
git pull
git checkout latest-scraped-definitions
asdf install nodejs 22.11.0
git checkout master

btw if you installed asdf with homebrew you might need to swap $ASDF_DIR with ${HOME}/.asdf. At least on my machine $ASDF_DIR pointed to the asdf installation in homebrew, whereas the plugins themselves are installed in ${HOME}/.asdf

[n-rodriguez]

Protip: you don't need to wait for a node-build release and can start using the latest version in asdf immediately like so:

Yeah, but how do you do when it's used in CI? in docker images? in short, everywhere?

[gnowland]

Yeah, but how do you do when it's used in CI? in docker images? in short, everywhere?

I don't want to get into an evangelical argument, and this is certainly off-topic, but my curiosity is getting the best of me... I thought using a runtime version manager in CI or Docker images an anti-pattern - my understanding is that containerization is specifically meant to address runtime management by abstracting its definition to the Dockerfile, that way each image version is explicitly reproducible. E.g. my node version is determined by the node image version used, and if there are other packages installed I use the OS package manager, but I've never had to use multiple versions of a runtime in one image... maybe it's because when I'm using containerization I usually go towards a microservice architecture?

Can you describe your use case?

[jasonkarns]

Agree with @gnowland . Version managers are kinda moot for CI or containers. And beyond being moot, they're certainly less performant that letting the container or CI infra handle the runtimes.

It's also worth noting the existing of the node-build plugin that's used for scraping the new version defs: https://github.com/nodenv/node-build-update-defs

That plugin can be used directly (locally) to scrape the definitions into node-build's definition path(s).

[n-rodriguez]

Can you describe your use case?

Python version (I don't have the node Dockerfile in hands right now) :

#################
# STAGE 1: base #
#################

# Fetch base image
ARG DISTRO_NAME
FROM jbox/base/asdf:latest-${DISTRO_NAME} AS asdf

# Set Python version
ARG PYTHON_VERSION

# Fetch release infos
ARG BUILD_DATE

# Tag image
LABEL python.build_date="${BUILD_DATE}"
LABEL python.version="${PYTHON_VERSION}"

# Switch to root user to install dependencies
USER root

RUN \
  # Install dependencies
  jbox-docker apt-install \
    libssl-dev \
    zlib1g-dev \
    libbz2-dev \
    libreadline-dev \
    libsqlite3-dev \
    libncursesw5-dev \
    xz-utils \
    tk-dev \
    libxml2-dev \
    libxmlsec1-dev \
    libffi-dev \
    liblzma-dev

# Switch back to nonroot
USER nonroot

###################
# STAGE 2: python #
###################

# Fetch image
FROM asdf AS python

# Set Python version
ARG PYTHON_VERSION

# Install Python
RUN \
  # Only use 4 cpus to build Python
  # See: https://github.com/pyenv/pyenv/blob/master/plugins/python-build/bin/python-build#L778
  export MAKE_OPTS="-j 4" && \
  asdf plugin add python && \
  asdf install python ${PYTHON_VERSION} && \
  asdf global python ${PYTHON_VERSION}

And still it's reproductible.

FYI : the asdf Docker image I use is build weekly alongside the Debian Docker image.

[n-rodriguez]

I thought using a runtime version manager in CI or Docker images an anti-pattern

I don't use asdf in CI (ie: I don't install nodejs when the CI starts/run) but I use asdf to build CI docker images.

[raygesualdo]

Thanks @jasonkarns!

[gnowland]

@n-rodriguez ah, that is interesting, indeed! Although because ASDF uses shims to support multiple runtime versions and it looks like for your use you're only ever using one runtime at a time you are definitely incurring a performance hit compared to using an os-level python install* for no reason methinks 🤷‍♂️🙂

*by either using the official python docker image or apt-installing python into a linux image, which is what the asdf image is doing anyway

[n-rodriguez]

@n-rodriguez ah, that is interesting, indeed! Although because ASDF uses shims to support multiple runtime versions and it looks like for your use you're only ever using one runtime at a time you are definitely incurring a performance hit compared to using an os-level python install* for no reason methinks 🤷‍♂️🙂

Well I always use a more recent version of Ruby/Python/NodeJS/Php/whatever than the one provided by Debian.

*by either using the official python docker image or apt-installing python into a linux image, which is what the asdf image is doing anyway

Actually it's not the case : asdf always recompile Python/Ruby during image build except for NodeJS where the binary version is curled from official repos or Php that comes from Sury repos.

[n-rodriguez]

@gnowland here a more complex version of Dockerfile (Ruby Docker image) :

Edit1 :

Note: Ruby has now a JIT written in Rust, so you need Rust and gcc to compile Ruby.

Edit 2 :

From my perspective asdf (in Docker) acts more like a package manager to install recent versions of tools than a "runtime version manager". I use asdf both in local environment (development) and during Docker image build.

#################
# STAGE 1: base #
#################

# Fetch base image
ARG DISTRO_NAME
FROM jbox/base/asdf:latest-${DISTRO_NAME} as asdf

# Set Ruby version
ARG RUBY_VERSION

# Fetch release infos
ARG BUILD_DATE

# Tag image
LABEL ruby.build_date="${BUILD_DATE}"
LABEL ruby.version="${RUBY_VERSION}"

# Switch to root user to install dependencies
USER root

RUN \
  # Install dependencies
  jbox-docker apt-install \
    gawk \
    libtool \
    pkg-config \
    libgmp-dev \
    libjemalloc-dev \
    libsqlite3-dev \
    sqlite3 \
    libssl-dev \
    zlib1g-dev \
    libffi-dev \
    libyaml-dev

# Switch back to nonroot
USER nonroot

#################
# STAGE 2: ruby #
#################

# Fetch image
FROM asdf AS ruby

# Set Rust version
ARG RUST_VERSION

# Set Ruby version
ARG RUBY_VERSION

# Set ruby-build version
ARG ASDF_RUBY_BUILD_VERSION

# Configure build options
ENV RUBY_CONFIGURE_OPTS --with-jemalloc --enable-yjit

# Set ruby-build version
ENV ASDF_RUBY_BUILD_VERSION ${ASDF_RUBY_BUILD_VERSION}

RUN \
  # Only use 4 cpus to build Ruby
  # See: https://github.com/rbenv/ruby-build/blob/master/bin/ruby-build#L547
  export MAKE_OPTS="-j 4" && \
  # Install Rust
  asdf plugin add rust && \
  asdf install rust ${RUST_VERSION} && \
  asdf global rust ${RUST_VERSION} && \
  # Install Ruby
  asdf plugin add ruby && \
  asdf install ruby ${RUBY_VERSION} && \
  asdf global ruby ${RUBY_VERSION} && \
  echo "gem: --no-document" > /home/nonroot/.gemrc && \
  # Remove Rust
  asdf uninstall rust ${RUST_VERSION} && \
  asdf plugin remove rust && \
  # Update bundler
  gem update --system && \
  asdf reshim