Well the PR is succesfull, but we run into nasty library linking errors later on:

 ERROR: LoadError: InitError: could not load library "/home/runner/.julia/artifacts/8a643038d2adde781829b4467a32afa307e23b51/lib/libproj.so"
/usr/lib/x86_64-linux-gnu/libcurl.so: version `CURL_4' not found (required by /home/runner/.julia/artifacts/8a643038d2adde781829b4467a32afa307e23b51/lib/libproj.

Locally stuff is also complaining, it might be because R, Python and Julia all use their own versions of GDAL libraries and place these things in the path. Python can't open fiona because gdal finds a library from julia first. Not sure how to fix this.

Fiona works fine in the python chunks. I sense that it links to the system installation of GDAL, not sure though. Is it possible to make Julia install packages linked to system installations? I would expect it to do that by default on Linux.

Any idea what's ArchGDAL?

https://github.com/Robinlovelace/opengeohub2023/actions/runs/6035489544/job/16375922642#step:11:651

That's just the stacktrace. I use GeoDataFrames, which depends on ArchGDAL (GDAL wrapper), which depends on GDAL, which depends on GDAL_jll, which actually executes the C calls to the library.

Julia bundles its own libraries, also for binary packages, just like conda does.

Julia bundles its own libraries, also for binary packages, just like conda does.

Is it possible to link to system installation of GDAL? Probably worth checking it works on vanilla Ubuntu + Julia without Quarto, to help eliminate other possibilities that should help diagnose the cause, e.g. confirm that it's JuliaCall, not sure how that would trigger the issue though. Could try on another OS?

Looks like progress with the env. Good luck and 🤞 to getting this working!

Zombie PR, but look at this!

Woohoo

What made it work?

Here it was setting the LD library path empty in one of the first R cells. That prevented horrible linking issues when running spatial stuff.

Haven't seen those issues yet with our newer attempts, so fingers crossed.