Document how to use Spack to replace Homebrew/Conda#13083
Document how to use Spack to replace Homebrew/Conda#13083tgamblin merged 3 commits intospack:developfrom
Conversation
adamjstewart
added
documentation
| sudo chown $USER:staff /usr/local/$directory | ||
| done | ||
|
|
||
| But again, it's safer just to use the default symlink location. |
There was a problem hiding this comment.
I'm obviously ignoring this, so I'll let you know if it causes any trouble.
There was a problem hiding this comment.
What is the main motive of this tutorial? Is it "how can I get spack to install things anywhere I want in a flat tree?" or is it "replace brew / anaconda specifically?" I think it could cover a couple of key usage capabilities if it becomes a little more general.
- Start with doing it in
~/installssince they can always write there - Enumerate the variables they'd need to update in their environment such as
~/.bashrcor similar. - Mention that you could do it in
/usr/local- Discourage doing a
chownof/usr/localfor security reasons, even if you are the only user on the system. (I don't think we need to explain that mac doesn't let you do it or any of that stuff, or if you do just link and say "hey it's disabled for a reason"). - Keep explain about how
/usr/localchoice can result in conflicts (other managers like brew, as well as it's default install location of Autotools, CMake, many others). - That said, here's a hack that works (
mkdirtrickery, which I still think is brilliant hehe).
- Discourage doing a
See what other people think though. It's nice because if you start that way, you have by contrast why doing the /usr/local thing is convenient. But since you show what variables need to update, you could also conjure another use case explanation: providing tools to multiple users. I can help compose that part if this sounds like something people want and you need help, it's just
- Put it in location they can all access, e.g.,
/opt/team_namesecured by group ownership. - Put a shell script that updates the same variables discussed in
~/installsapproach iff groupid is the same (exclusive access for just the team!).
There was a problem hiding this comment.
I'm still thinking about this. The intent of this workflow is specifically how to replace Homebrew/Conda with Spack. There are other sections of the docs already devoted to more generic usage of Spack Environments and flat installation hierarchies:
I do like your suggestions for enumerating through the list of env vars you need to set to contrast why you might want to use /usr/local, but you can also just spack env activate myenv and it will set all of these automatically for you, much like module load would.
| .. code-block:: console | ||
|
|
||
| $ spack env activate myenv | ||
| $ spack uninstall --all |
There was a problem hiding this comment.
This doesn't actually work. All of my symlinks are still in place after an uninstall. Is this a known bug?
svenevs
left a comment
svenevs
left a comment
There was a problem hiding this comment.
This is really cool @adamjstewart! Mostly small fixes / suggestions (feel free to mark resolved w/o action, some are very minor). Main discussion point is really just can we make it more general? I hope it's coherent, wanted to review before sleep but it's been a long day and I've edited the thing above too many times now
| By default, users don't have permissions to install anything in ``/usr/local``, | ||
| and you can't even change this using ``sudo chown`` or ``sudo chmod``. |
There was a problem hiding this comment.
change to:
Users administering their personal workstation are not able to take ownership of
/usr/localusingchown.
Linux doesn't allow just anybody to install to /usr/local by default either. AFAIK it's existence is to make the lives of sysadmins easier, /usr by contrast is for the system package manager.
Though to be honest, I think explicitly chowning /usr/local is a bad idea even if you can...
There was a problem hiding this comment.
I think your wording makes it less clear that you can't even install things to /usr/local. If I was reading this, I would say, "that's fine, I didn't want to take ownership of it anyway".
| sudo chown $USER:staff /usr/local/$directory | ||
| done | ||
|
|
||
| But again, it's safer just to use the default symlink location. |
There was a problem hiding this comment.
What is the main motive of this tutorial? Is it "how can I get spack to install things anywhere I want in a flat tree?" or is it "replace brew / anaconda specifically?" I think it could cover a couple of key usage capabilities if it becomes a little more general.
- Start with doing it in
~/installssince they can always write there - Enumerate the variables they'd need to update in their environment such as
~/.bashrcor similar. - Mention that you could do it in
/usr/local- Discourage doing a
chownof/usr/localfor security reasons, even if you are the only user on the system. (I don't think we need to explain that mac doesn't let you do it or any of that stuff, or if you do just link and say "hey it's disabled for a reason"). - Keep explain about how
/usr/localchoice can result in conflicts (other managers like brew, as well as it's default install location of Autotools, CMake, many others). - That said, here's a hack that works (
mkdirtrickery, which I still think is brilliant hehe).
- Discourage doing a
See what other people think though. It's nice because if you start that way, you have by contrast why doing the /usr/local thing is convenient. But since you show what variables need to update, you could also conjure another use case explanation: providing tools to multiple users. I can help compose that part if this sounds like something people want and you need help, it's just
- Put it in location they can all access, e.g.,
/opt/team_namesecured by group ownership. - Put a shell script that updates the same variables discussed in
~/installsapproach iff groupid is the same (exclusive access for just the team!).
|
The more I play around with this, the more I'm realizing that it's actually a bad idea (at least for maintainers/me) to use |
|
@tgamblin @scheibelp can I bug you for a review? |
|
Ping @tgamblin @scheibelp |
|
@adamjstewart -- have you run into #2230 and if so, found a solution? |
|
Nope, I've never encountered that. I've also never tried to build anything substantial on macOS with GCC. I only use system Clang + GFortran. GCC is installed with Spack, not Homebrew. I use Python 3.7.4. If you're using GCC and encountering that problem on macOS with Python 3.7, you're best bet is to report it to the Python developers. We can try to work hacks into the |
|
@adamjstewart -- It might be useful to make a reference to the docs for setting up mixed toolchains, I only just found this section after a couple of other dry searches (I'd found references in a couple of Issues, but it wasn't clear that it was the blessed approach). Although I suppose that other Mac users might have read the Getting Started page more recently..... |
|
Ping @tgamblin @scheibelp |
| $ spack env create myenv | ||
| ==> Updating view at /Users/me/spack/var/spack/environments/myenv/.spack-env/view | ||
| ==> Created environment 'myenv' in /Users/me/spack/var/spack/environments/myenv | ||
| $ spack env activate myenv |
There was a problem hiding this comment.
this step probably needs to be clearer to new users that this needs to be run to 'activate' the environment, i suspect new users will gloss over it, run all the above steps, at somepoint reboot restart their shells and things won't work as expected for them
|
Once #14695 is addressed, this will be another thing we'll want to add to these docs. Basically, we'll be able to replace |
|
@adamjstewart: is this ready to be merged in some form? It’d be nice to get into 0.14 |
|
I think the current state is safe to merge. It's far from perfect, but it's a good starting point, and we can iterate on it as new features are added/new workflows arise. |
5 participants
Decided to finally drop Homebrew and Conda in favor of Spack for all of my software installation needs. This PR documents the process.
@svenevs @tgamblin