Could we replicate the Anaconda batch mode? spack install --batch???

Some packages (like anaconda) would require batch mode. If you're not in batch mode, spack install would find all the batch mode packages and print their batch_msg() --- presumably telling you about license agreements, etc. Once you're done reading all the fine print, you can rerun spack install --batch-mode.

But also you're right... I'm absolutely not thrilled about installing Conda with Spack --- for the same reasons that Lua, PIP, etc. create problems. What is the advantage of installing Conda from Spack, vs. just installing it yourself and then using it to install UV-CDAT. Either way, it looks like UV-CDAT wouldn't really be integrated in with the rest of the Spack Python ecosystem.

Would we do better to see if UV-CDAT can be modified to not require Conda? They only started requiring Conda in the current version --- maybe they can be talked out of it if Spack users speak up loudly.

Also, the installation script hangs after it is done much like my matlab package. Not sure how to resolve that.

If you let it run for like 10 minutes, you'll find that it's actually patching shebangs that whole time. There are so many subdirectories and files in the installation that it takes a while.

[quoted bits out of order, sorry...]

Would we do better to see if UV-CDAT can be modified to not require Conda? They only started requiring Conda in the current version --- maybe they can be talked out of it if Spack users speak up loudly.

"My way or the highway" isn't going to work. The Spack community can't generally run around and ask every other language/group/team/project to give up their build infrastructure and re-arrange their world to use Spack.

Even if you manage to get your cow-orkers to see the error of their ways and clean up their act, I'm still stuck with my Conda-loving Perl-using Java-drinking Gophers (and I love each and every one...).

We (honorarily including myself...) need to figure out a way to work with their machinery. We might:

• shrug and say that Spack doesn't support ecosystems that have their own infrastructure (except those for which we've already bent over backwards and bound ourselves tightly with [python, lua]);
• spin up specific mechanisms for every such ecosystem and spend the rest of our lives chasing their universe (texlive, I'm looking at you...); or
• figure out some way to loosely couple to these other worlds.

But also you're right... I'm absolutely not thrilled about installing Conda with Spack --- for the same reasons that Lua, PIP, etc. create problems. What is the advantage of installing Conda from Spack, vs. just installing it yourself and then using it to install UV-CDAT. Either way, it looks like UV-CDAT wouldn't really be integrated in with the rest of the Spack Python ecosystem.

You ask about the advantage of installing Conda via Spack vs. doing it by hand; I think it has the same advantage I've brought up in the past (provides a single reproducible interface to do the parts that can be done reproducibly [@tgamblin liked it when I said "platform" in #2128]).

I'm worrying at the npm bone again, which is another perfectly annoying instance of this problem and trying to think of some ingenious and earth-shattering solution to the problem.

In the meantime, I'm in favor of using Spack to get the platform bits in place.

Ran into a new issue. When I tried to install UV-CDAT with conda, I got the following error:

PaddingError: Placeholder of length '80' too short in package uvcdat::binaryio-2.8-np111py27_2.
The package must be rebuilt with conda-build > 2.0.

I think this may be due to the extra long shebang. I'll try installing Anaconda outside of Spack and see if it works.

On the other hand....

Package managers managing package managers rarely works out well.

(from this oldish homebrew issue)

For the record, I installed Anaconda2 by hand and installed UV-CDAT and it didn't have the aforementioned problem. So this package isn't working properly, possibly due to the long shebangs. I'm marking this as up-for-grabs as I no longer need to delve any further into this.

Shall we add a pakcage named anaconda for Python 3?

Closing this as I never got it working. If anyone needs it, feel free to pick up where I left off.