Spack cannot concretize R specs #2546
Comments
|
@hartzell This looks to me like a problem in the R package: Depending on things
I don't believe that the Cairo API or Tk is tied into X. Therefore, shouldn't the variant on |
|
For the time being, you have a few options. This works: You can also set pango to default to |
$ spack spec R ^pango+XThis works for me. Thanks! |
|
This quirk was discussed as part of the pull request that added X support to R, #2053. The only way I could get my POC set of apps to build end-to-end last week (yay) was by doing what @adamjstewart suggested above (I actually spec'ed by cairo and pango because it worked when I tried it and then I moved on, I'll try @adamjstewart's shorter version). But, I then needed to add similar prereq's for that R for each r-this and r-that package I installed. ick(tm). I have a half finished issue/question on my machine at work to see if I can do better while waiting for the improvements @adamjstewart mentions above.
Something needs to be cleaned up there too. I've always thought of Tk as an X windows toolkit, but apparently it can build on OS X w/out X. My current thought is that perhaps R would be build-able with/without Tk and that Tk should be window_system=X or some such. I walked face-first into this topic because I needed to have R build with a Cairo that was built with X in order to get the PDF's that R generated to use glyphs for fonts instead of simply drawing bounding boxes (discovered while serving plots from an R shiny server) even though there isn't an X display anywhere in sight. I'm unclear why that should be so and suppose I'll have to invest some neurons into understanding the R build/assembly process. I'm working towards a package for the open source R shiny server, which has prerequisites for node and npm (which is the topic of #2128) and me getting all of these bits to sing in harmony. As always, thanks to @everyone (and the rest of you too!). |
|
I looked up the arguments to R's configure (see below). It is my opinion that we would do well to go through that list carefully and be more careful about the command line arguments we pass to R's configure. It is also my opinion that if you don't want to do X11 with R, then it should just That would have avoided the problem in this Issue. This will still lead to non-intuitive behavior: specifically, that if
I believe that (2) is really the right way to go; and could be done with zero or minimal changer to the current infrastructure. I'm beginning to believe it's a better alternative to variant forwarding (which seems messy). |
This doesn't fix anything. I tried commenting out the
I think we want the same thing here. Basically, if I ask for |
There is a fine line between a hack and a parsimonious re-use of infrastructure. I'm not sure which one this is yet. :-)
Let's see what it would mean by thinking through an example. For every universal variant we desire, we make a dummy package for it. So for the Now... packagaes that used to offer a variant they will do: Similarly, The results of this would be:
With this in mind, answers to questions above:
no
No. This is why each universal variant needs its own meta-package.
I think the principles are sound, but the resulting syntax leaves a bit to be desired. Some Spack support on cleaning up the syntax would be helpful; syntactic suger is usually easier than deep reworkings of complex algorithms. But this could be as decent a way as any to implement universal variants / variant forwarding. |
|
F.W.I.W. (and for future reference for me), here's how I've been building my R bits (just ran through that part of the build with commit |
|
@hartzell You can also put the following in packages:
R:
variants: +X
pango:
variants: +Xand run: to get the same effect. |
|
Yes, but that only works if the job runs as me, on a machine that has that file in my home directory. The command I shared does not depend on any configuration outside of the repo. Making those changes in my home directory feels a bit like 'spooky magic at a distance', which usually leads to trouble.... I believe (have not tested) that I could get the same effect in an For now, being explicit works. Thanks for the follow up! |
|
works! I do not think X should be the default variant in headless HPC environment. |
|
Closing as no longer reproducible. |
|
It's no longer reproducible because I hacked every package to default to |
I need to build tk+X for as a dependency for R. I can't create a spec to do this that does not produce a CLI error.
I also tried this, same result
This too
$ spack spec R ^tk+X ^cairo~X Input spec -------------------------------- R ^cairo~X ^tk+X ... Concretized -------------------------------- ==> Error: Invalid spec: 'tk@8.6.5%gcc@4.8.5+X arch=linux-rhel7-x86_64'. Package tk requires variant ~X, but spec asked for +XSpecing cairo+X AND cairo~X does not produce errors. I was able to
spack installtk+X, cairo~X and cairo+X independently. I'm also able to produce errors like these on Ubuntu with d7e9134.The text was updated successfully, but these errors were encountered: