Hey there! We've found the following might help you get unblocked faster:

• 🧵 Unknown Error Starting a Railway container

• 🧵 Consistently unable to apt install and connect to [archive.ubuntu.com](archive.ubuntu.com) with nixpacks

• 🧵 Failed to integrate Astrojs API with backend service in Python/FastaPI via railway.internal.

If you find the answer from one of these, please let us know by solving the thread!

Worth mentioning... While my project is in Python, there is an npm version of Sass I could use (it's slower, but it would work). Will a Railpack-based installation be able to install dependencies from both?

I attempted to set up a pre-deploy script to install the npm version, but—as I feared—the Railpack installer had already decided (correctly) that this was a Python project, and therefore didn't install npm. So... no luck along that avenue. :-(

hey andrewminer , yeah Railpack can totally handle python +node together just add these env vars in your service settings:

RAILPACK_PACKAGES = node (pulls in Node via Mise during build)

RAILPACK_INSTALL_COMMAND = pip install -r requirements.txt && npm install -g sass

that installs your Python deps, then Sass via npm—Flask-Assets should find the sass command no prob. For the faster native version, swap the npm part with

curl -L https://github.com/sass/dart-sass/releases/download/1.94.2/dart-sass-1.94.2-linux-x64.tar.gz -o sass.tar.gz && tar -xzf sass.tar.gz && mv dart-sass/sass /usr/local/bin/ && rm -rf dart-sass sass.tar.gz

(add RAILPACK_BUILD_APT_PACKAGES = curl tar if needed)

on apt, no direct Dart Sass package—apt-cache search sass shows old stuff like sassc (LibSass) or ruby-sass (deprecated).

redeploy and test with sass --version in the shell

I'm afraid this didn't get me there. Adding node to RAILPACK_PACKAGES did install NodeJS correctly. I then updated my build script to include:

#/usr/bin/env sh

VENV_DIR="./authmo/venv"
python -m venv "${VENV_DIR}"
if [ ! -d "${VENV_DIR}" ]; then
    echo "Failed to create virtual env."
    exit 125
fi

. "${VENV_DIR}/bin/activate"
echo "Using pip: $(which pip)"

pip install --upgrade pip
pip install authmo_common@git+https://${GITHUB_USER}:${GITHUB_TOKEN}@github.com/authmo/common
pip install authmo_sql@git+https://${GITHUB_USER}:${GITHUB_TOKEN}@github.com/authmo/sql
pip install .

npm install -g sass
echo "Using sass: $(which sass)"

In the build log, I do see the line "Using sass: /mise/shims/sass" at the end. So, it appears that the installation worked correctly. However, using this script for starting the server:

#/usr/bin/env sh

VENV_DIR="./authmo/venv"
. "${VENV_DIR}/bin/activate"

echo "Using python: $(which python)"
echo "Using sass: $(which sass)"

SERVICE_NAME="www2-web" python -m gunicorn "authmo_www.web.server:launchApp()"

I see "Using sass: " in the Deploy log. So, it appears that sass was removed somewhere between the build completing and the server starting.

Out of curiosity, I added these lines to my startup script:

    if ! which sass; then
        npm install -g sass
    fi
    echo "Using sass: $(which sass)"

Sadly, it didn't help. In the deploy log I see:

Starting Container
Using python: /app/authmo/venv/bin/python
node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
Using sass: 

Curious, what do you need sass for at runtime?

I'm using Flask-Webassets to serve up dynamically generated, hashed, compressed, etc. versions of my SCSS files. Super handy for development, and (until now) very simple to deploy along-side the server. It caches everything, so it's just as fast at runtime without having to fuss about setting up a separate asset build pipeline. I've done the whole webpack thing (or browserify if you reach back far enough) thing on past projects, and this has been much simpler... until now. :-(

I finally figured out a solution: just install what I need myself and ignore all the Railway-provided machinery. Here's the final version of the build script:

#/usr/bin/env sh

VENV_DIR="./authmo/venv"
PIP="$VENV_DIR/bin/pip"
PYTHON="$VENV_DIR/bin/python"


# Create Virtual Environment #######################################################################

python -m venv "${VENV_DIR}"
if [ ! -d "$VENV_DIR" ]; then
    echo "Failed to create virtual env."
    exit 125
fi

. "$VENV_DIR/bin/activate"


# Install Python Dependencies ######################################################################

$PIP install --upgrade pip
$PIP install authmo_common@git+https://${GITHUB_USER}:${GITHUB_TOKEN}@github.com/authmo/common
$PIP install authmo_sql@git+https://${GITHUB_USER}:${GITHUB_TOKEN}@github.com/authmo/sql
$PIP install .


# Install Sass #####################################################################################

cd bin
DOWNLOADS_URL="https://github.com/sass/dart-sass/releases/download"
SASS_URL="$DOWNLOADS_URL/1.94.2/dart-sass-1.94.2-linux-x64.tar.gz"
echo "Downloading Sass from: $SASS_URL"
curl -o sass.tgz -sSL $SASS_URL
tar -xf sass.tgz
rm -rf sass.tgz
cd ..

if [ ! -x ./bin/dart-sass/sass ]; then
    echo "Failed to install sass"
    exit 125
fi

And the final version of the start-up script:

#/usr/bin/env sh

VENV_DIR="./authmo/venv"
PIP="$VENV_DIR/bin/pip"
PYTHON="$VENV_DIR/bin/python"
SASS="$PWD/bin/dart-sass/sass"

. "${VENV_DIR}/bin/activate"

export SERVICE_NAME="www2-web"
export SASS_BIN="$SASS"
$SASS --version

python -m gunicorn "authmo_www.web.server:launchApp()"

There were a good many key insights I had to learn by trial-and-error since they weren't documented anywhere I could find:

1. Your build script starts out in /app, with the contents of your linked repo already present in that directory.

2. Only the contents of your /app directory survive from the build step to the deploy step. Everything outside that directory (including stuff installed via mise or apt) is discarded between those two stages.

3. Installing global node packages is useless due to the above.

4. Installing mise or apt packages is likewise useless, despite what the documentation implies.

5. Any Python virtual environment venv) directories you create must also be inside the /app directory.

6. The OS is some version of Ubuntu on some flavor of an x64 chip.

7. The shell is dash: a bare-bones posix-compliant micro shell. You cannot count on even basic conveniences from bash (e.g., source instead of .). Assume your scripts must work in sh, and you should be okay.

8. Railway can only handle installing a single, root-level private repository. If that repository has dependencies which are also private repositories, you have to handle them yourself in your build script.

9. Railway cannot manage any form of git+ssh when resolving dependencies. You need to use git+https, instead. If you're on GitHub, this will require you to create a Personal Access Token (PAT) which is buried in the "Developer" section of your GitHub account. The url takes the form of: git+https://{username}:{token}@github.com/{account}/{repo}. The username must be the user who created the token.

10. You're on your own. Unless Railway decides your problem is definitely due to something in their stack (and a total lack of documentation on writing build scripts doesn't count), they're going to make your issue public, slap a bounty on it, and hope someone else will help out. Based upon my empirical evidence from this issue, there's a 50/50 shot someone will feed you ChatGPT gibberish at 60min intervals to claim the bounty.

You're on your own. Unless Railway decides your problem is definitely due to something in their stack (and a total lack of documentation on writing build scripts doesn't count), they're going to make your issue public, slap a bounty on it, and hope someone else will help out. Based upon my empirical evidence from this issue, there's a 50/50 shot someone will feed you ChatGPT gibberish at 60min intervals to claim the bounty.

A lack of documentation is definitely on us. Apologies you're experiencing this (and ChatGPT gibberish - we try to drop the banhammer as fast as we can on them). Improving Railpack documentation and providing recipes/examples is definitely somthing we should be doing, so I'm sorry for the poor experience here.

Thank you, Ray. I appreciate you saying so. Please let me know if you have any questions about my specific set-up which will help in improving the documentation around Build and Start-Up scripts.