Installation fail due to gitlab connectivity issue on remote machine

[marcoBmota8]

Development installation of the main GitHub brunch fails: pip install git+https://github.com/StochasticTree/stochtree.git
It looks like th libeigen/eigen dependency is the culprit somehow.
I tried also cloning the repo locally and installing that and I get to the same issue.
The pushed package installation (i.e. pip install stochtree) doesn’t throw any errors though: pip install stochtree

Here are the error logs I am getting:

Collecting git+https://github.com/StochasticTree/stochtree.git
  Cloning https://github.com/StochasticTree/stochtree.git to /tmp/pip-req-build-0kiizflb
  Running command git clone --filter=blob:none --quiet https://github.com/StochasticTree/stochtree.git /tmp/pip-req-build-0kiizflb
  Resolved https://github.com/StochasticTree/stochtree.git to commit f33c099cf14ed0642514a76d545bd386334d736e
  Running command git submodule update --init --recursive -q
  fatal: unable to access 'https://gitlab.com/libeigen/eigen/': Operation timed out after 300037 milliseconds with 0 out of 0 bytes received
  fatal: clone of 'https://gitlab.com/libeigen/eigen' into submodule path '/tmp/pip-req-build-0kiizflb/deps/eigen' failed
  Failed to clone 'deps/eigen'. Retry scheduled
  fatal: unable to access 'https://gitlab.com/libeigen/eigen/': Operation timed out after 300000 milliseconds with 0 out of 0 bytes received
  fatal: clone of 'https://gitlab.com/libeigen/eigen' into submodule path '/tmp/pip-req-build-0kiizflb/deps/eigen' failed
  Failed to clone 'deps/eigen' a second time, aborting
  error: subprocess-exited-with-error
 
  × git submodule update --init --recursive -q did not run successfully.
  │ exit code: 1
  ╰─> See above for output.
 
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
 
× git submodule update --init --recursive -q did not run successfully.
│ exit code: 1
╰─> See above for output.
 
note: This error originates from a subprocess, and is likely not a problem with pip.

[andrewherren]

Hi, thanks for raising this issue!

It seems like it might be a network issue as opposed to something with stochtree, but let's see if we can find a workaround. Can you share more details about the platform you're using (i.e. windows, macos, linux)?

You mentioned that you tried cloning the repo and installing it locally. When you did that, did the local clone of eigen go through? (You can check this by looking in the deps/eigen subfolder of your local stochtree clone.)

Finally, are you able to git clone Eigen directly from gitlab? If that doesn't work, I suspect the issue is with access to gitlab (which we should still be able to find a solution to, I just want to understand whether or not that's the root of the error).

[andrewherren]

Hi @marcoBmota8, just checking in on this. I'd love to understand the issue you're having in more depth so I can make sure other users don't encounter it.

[marcoBmota8]

Here are some more details:

1. I am on a remote machine using Linux kernel version 5.14.0-503.14.1.el9_5.x86_64.
2. The clone does have deps/eigen but looks like that folder is empty.
3. I can ping gitlab no problem however there seems to be some issue accessing gitlab when cloning dependencies:

git` clone https://gitlab.com/libeigen/eigen.git

Cloning into 'eigen'...
fatal: unable to access 'https://gitlab.com/libeigen/eigen.git/': Operation timed out after 300039 milliseconds with 0 out of 0 bytes received

[andrewherren]

Hmmm, that is truly a strange phenomenon! It seems like an issue with your remote machine's ability to access Gitlab via git.

Are you able to use curl / wget on the remote machine to download the Eigen repo as a zip file or tarball?

The URL for a zipfile download of the Eigen source (for the 3.4 branch) is: https://gitlab.com/libeigen/eigen/-/archive/3.4/eigen-3.4.zip

And the URL for a tarball download is: https://gitlab.com/libeigen/eigen/-/archive/3.4/eigen-3.4.tar.gz

If you can download the repo as a tarball, you can unpack it into deps/eigen and then everything should work as needed.

[marcoBmota8]

Hmmm, that is truly a strange phenomenon! It seems like an issue with your remote machine's ability to access Gitlab via git.

Are you able to use curl / wget on the remote machine to download the Eigen repo as a zip file or tarball?

The URL for a zipfile download of the Eigen source (for the 3.4 branch) is: https://gitlab.com/libeigen/eigen/-/archive/3.4/eigen-3.4.zip

And the URL for a tarball download is: https://gitlab.com/libeigen/eigen/-/archive/3.4/eigen-3.4.tar.gz

If you can download the repo as a tarball, you can unpack it into deps/eigen and then everything should work as needed.

None of that worked, so yes something is firewalling downloads from gitlab via git. What did work was to locally download the tarball, transfer it over to the remote machine and unpack it.
However, I tried to install the repo via pip install . and that crashes. There is probably stuff that should have been installed after eigen when cloning the repo and it did not due to the error hard stop and/or pip doesnt like this manual workaround installation.

Looks like pybind11 was missing (i was able to fix that) and now fast_double_parser.h seems to be the issue:

During the compilation of several .cpp files

fatal error: fast_double_parser.h: No such file or directory
         27 | #include <fast_double_parser.h>
            |          ^~~~~~~~~~~~~~~~~~~~~~
      compilation terminated.

. I am not able to get that solved. I tried git clone https://github.com/fastfloat/fast_float.git fast_double_parser but doesnt seem like that installs the correct dependency.

[andrewherren]

Hmmm, interesting. I wonder if there's a workaround for eigen that involves using the conda-forge version of the library. That would require me to write a bunch of flexibility into the build process that I don't have bandwidth to do right now, but I'll make a note in case this ever comes up again.

Regarding the rest of the submodules, fastfloat/fast_float is indeed not the not the correct dependency for the fast_double_parser library. You can see the full list of git submodules (all of which get unpacked into deps/) in the stochtree .gitmodules: https://github.com/StochasticTree/stochtree/blob/main/.gitmodules

fast_double_parser comes from here, so to unpack it into deps/fast_double_parser you'd run something like

git clone https://github.com/lemire/fast_double_parser.git deps/fast_double_parser

Ditto for the rest of the dependencies (all of which are hosted on github besides Eigen, so hopefully won't present you with any further issues)

[marcoBmota8]

Okay, so it looks like manually removing the dependencies that stochtree direct installation created and manually installing them one by one solves the issue and allows to install the package development version.

After fast_double_parser, fmt also gave issues:

fatal error: fmt/format.h: No such file or directory
         28 | #include <fmt/format.h>
            |          ^~~~~~~~~~~~~~
      compilation terminated.

But the manual work worked!

Thanks @andrewherren for the quick responses and guidance!

[andrewherren]

Very interesting! It's super helpful and important for me to understand that there are some server development environments that firewall our Gitlab dependency. I'm not sure there's a clean "fix" here as opposed to recommending the workaround you proposed, but it does raise the exigency for me to make another PyPI / CRAN release. Thanks for being patient and I'm glad you have the development version of stochtree installed now!